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TS ^5.331 V1 ;1 ,0 (1999^06) 



1. Scope 

The scope of this specification is to describe the Radio Resource Control protocol for the 3GPP radio system. 



2. References v ^ . ) ^ 

[1] UMTS 25.XX, Vocabulary for the UTRAN' ' , 

[2] 25.301, Tladio Interface Protocol Architecture' - , , . . 

[3] 25.303, Description of UE states and-procedures in connected mode' 

3. Definitions, Symbols and abbreviations, , 
3.1 Definitions 

See [1] fc)r definition of fundamental concepts and vocabulary 



3.2 


Abbreviations 


ACK 


Acknowledgement 


AS 


Access Stratum 


BCCH 


Broadcast Control Channel 


BCFE 


Broadcast Control Functional Entity 


CCCH 


Common Control Channel 


CN 


. Core Network 


DCA 


Dynamic Channel Alloaition 


DCCH 


Dedicated Control Channel 


DCFE 


Dedicated Control Functional Entity 


DCH 


Dedicated Channel 


DTCH 


Dedicated Traffic Channel 


FACH 


Forward Access Channel 


FAUSCH 


Fast Uplink Signalling Channel 


FDD 


Frequency Division Duplex 


FFS 


For Further Study 
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ID • Identifier 

LI Layer! 

MAC . Media Access CoTitrol , . . . j. . * . . ' 

MS Mobile Station 

NAS . Non Access Stratum 

NW Network 

ODMA Opportunity Driven Multiple Access * 

PCCH ' Paging Control Channel 

PCH Paging Channel 

PNFE Paging and Notification Control Functional Entity 

QoS Quality of Service ^ • * ^ ^ 

RAB Radio access bearer 

RLG . ^RadioLinkControL^ V - * - - > . 

RNTI Radio Network teiiaporary Idetitifier- - = '^^ 

RFE Routing Function^ Entity 

RNC Radio Network Controller 

RRC Radio Resource Control 

SAP Service Access Point 

TDD Time Division Duplex 

TF Transport Format 

TFCS Transport Format Combination Set 

TFS Transport Format Set 

TME Transfer Mode Enitity 

UE User Equipment 

UMTS Universal Mobile Teieconununications System 

UN ACK Un ackn owledgemen t 

UTRAN UMTS Terrestrial Radio Access Network 



4. 



General 



The functional entities of the RRC layer are described below: 



• Routing of higher layer messages to different MM/CM entities (UE side) or different core network .domains ^ 
(UTRAN side) is handled by the Routing Function Entity (RFE) 
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• Broadcast functions iire haDciled in the broadcast controi function entity (BCFE). BCFE offers RRC services by 
tbe GC-SAP and iises the lower layer services provided by'Tr-SAP. . 



• Paging of idle mode UE(s) is contf oiled by the paging and liotifiGfition- control function entity (PNFE). PNFE 
offers RRC services by the Nt-SAP and uses the lower layer services provided by Tr-SAP. 

• The Dedicated Control Function Entity (DCrE)'handles Ml functions specific to- one UE. The DCFE offers RRC 
services by the DC-SAP and can use lower layer services of XJM/AM-S AP and Tr-SAP depending on the message 
to be sent and on the'current UiE service state;-- ] '--r^- r' V • 

• The Transfer Mode Entity (TME^ handles theniapping between :the"different en ti^^^ inside the RRC layer and 
the SAP's provided by RLC. " " i r ■ ^ > ■ / . . ^ 

Logical information exchange is necessary also befWeen the RRC.'Subl(^erfu of that is 

implementation dependent and not necessary to, present iii^ 'd^^^ in q^sp^^ ^ . , ^ _ j 

. ^ '" ■ . . ' '*v ■ ^ ' ■ ' * 

Figure 1 shows the RRC model for the UE side and Figure 2 shows the RRC model for the UTRAN side. 

[Editors note: Some further clarification in the diagrams may be beneficial to acknowledge the fact that a DC-SAP 
for example might be offered over a dedicated charmei(with 1^ whereas GC-SAP and Nt-SAP 

may be offered over BCCH, PCH respectively in which cdses RRC is locdted in Node B. It^couldbe concluded from 
the figure that these channels use the same SAP offered by RLC (Tr-SAP, UM-SAP, AM-SAP) whkreas in fact they will 
use different SAP's, though the SAP type might be the same] 



NAS 



DC-SAP 



GC-S>^P 



SAP. GC 



Nt 



SAP 

t t-SAR Nt-feAP 



RFE RFE ^ 



.J 



Dq-SAP 

DC 



-SAP . DC 




RRC 



AfV SAP 



Figure 1) UE side model of RRC 
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4) 



NAS 



r I 



DCrSAP , 



GC-SAP 



SAP 



J 



DC -SAP 



DC -SAP . DC 



SAP 




.Ll.-ctri 



Figure!) UTRAN side RRC model 



5 RRC Services pro 

The RRC offers the fbil6wi;ig services, to upper layers, a description Of these services is provided in [2]. 



• General Control 

• Notification , '. 

• Dedicated control 



6 Services expected from lower layers 
6.1 Services expected from. Layer 2 



6.2 



r 1 



7 Functions of RRC 

The RRC performs the functions listed below, a more detailed description of.these functions is provided in YY.Ol: 
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Broadcast of information provided by tiie non-access stratum (Core Netsvork)* " ' . 
Broadcast of information related to the access stratum. 

Establishment, maintenance and release of an RRC connection between the UE and OTRAN. 
Establishment, reconfiguration and release of Radio Access Bearers 
Assignment, reconfiguration and releiase of radio resources for the RRC connection. 
RRC connection mobility functions. 

Arbitration of the radio r^ource aUec^tJon; Between the cells. 

Control of requested QoS. ' ^ 

UE measurement reporting and control of the reporting. 
Outer loop power control. 

Control of ciphering. , , 

SlQwDCA., ■ .^^ . ' ;-7.i.-, -.; n , .; ' ^,.'.y-\. 

Broadcast of ODMA relay node neighbour Information li : \ ... ; 0 • : 

Collationof ODIVL^ relay nodes neigb^^ , V . . . ^ . ^ t : 

Maintenance of nunijber of QDMA relay node nei^^ . , - 

Establishment, maintenance and release of a routesbetweenOD]^ ' . : 

Interworldng between the Gateway ODMA relay^^^^ 

Contention resolution (TDD mode) ' » 

Paging/notification. ^ - ::v / . = . . ^ 

The fbUovmg fiHictions are regarded as ..i'/.i*.^: r • . t v;/ 

Initial cell selection and rerselection in idle mode.^ ^ , t ;■ . ■ k /: . ; i . ; f : i: i 

Congestion control.' ^ ^ , . k^^ ;r-r>a:roobnii:c-a 

Routing of higher layer PDU's (in UE side to correct higher layer entity and in UTRAN side to correct 
RANAP entity). The requirement for this function iwiUIbe dependent on the decision inade fey §MQ1>-: > ; 

8 Elementary RRC procedures . ; 

This section describes elementary RRC procedures used in the idle mode and in the connected mode. More description 
on the different UE modes is provided in [2].This section also describes procedures.for,estabUshing and releasing.an 
RRC connection. 
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8.1 Idle mode procedures ^ : ; ^ 
8.1.1 Broadcast of system .inforiTi.ation, 



UE 



UTRAN 



SYSTEM TNFQRMATIOr^ . 



Figure 3) Procedure for broadcast of system Information 

This procedure is used for broadcasting system information from the network to aU UEs in a cell. Only UEs that 
listen to the logical channel BCCH am be reached by this procedure. The system informauon is repeated on a regular 
basis and it includes information from both the access stranm^ and.the non-access stratum. Tlie miuauye to change the 
system information can come from both the access stratiiin^arid non-access straitum. " ' ' " 

The SYSTEM INFORMATION message is regularly b^baddast 6n the BdH by the UTRAN. Based on this information 
the mobile station is able to decide whether and^hbwit^may^gain^access to the system via the current celL. . . 

The contents of the SYSTEM INFORMATION messag& c^^^ and from the physical layer • 

niGasut&n&nXs of e^chcQll [Editors note: Other sources for the system information are also alh^^ 

The information may be grouped mto the following classes: 

- information giving unique identification of the current network; location area,^ UTOAN registration area and ceU 

- information used for candidate cell measurements for handover mi cell sblectibn procedures 

- information describing the ciOTcnt con t^^^^^ ■ - . . 

- informatiOT'GbiytroUing ti^^^ ' ' ^ ' ' ' 

-'information defining4ifferent options supp(SffXed.witi^^^ ....... ^ . • 

- protocol information v ..^^ . ! ^ ' r ..j 

[Note f The set hf messages that forms t he system dnformatiorv is FFS. However, :basically the $ame elementary ^ , . 
procedure can be applied for all messages J^^ .'-^ ■■. ... • • ' ; • -* • * ■< - "J 



8.1.2 



Paging 



UE 



UTRAN 



PAGING TYPE 1 



Figure 4) Paging procedure 

This procedure is used to broadcast a PAGING TYPE 1 message from the network to selected UEswhich are in idle 
mode. Only UEs which listen to the correct paging group am be reached by this procedure. The PAGING TYPE 1 
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message can be'seiu to eitJierone-W mhh : • ■ x J . • . - ' 

[Note, the following is FFSJ: The PAGING TYPE 1 message includes BCCH Modification Information, which 
indicates the modification of the System Information on BCCH. The coding of BCCH Modification Information is 

FFS;.'" - • '''' ' - :: i-.^ . \ ' . , • r . ..• r . i A. 

[Note: The addresses which are to be used in the paging message (eg IMUI etc) are still to be defined] 

[Note: The number of addresses to be. used in the :pa^^^ . . ",. . . 

[Note: the requirement to have different paging messages for UTRAN originated and CN originated RRC connected ' 
mode paging needs to be confinned]' . . .,. . j . v, ^ ... - - • . . ; . 

8.1.3' ^ Notification-'. " ■ ^ IZ'''''''^:: '\:: ■ ' ■■•/■^l.V;--: Z:; ,'■''-..'-■■]' "'''1 



UE 




-IJTRAN . 




<— 


- ^ ' NOTIFICAnnON' 

















This procedure is used forrbroadcast of notification information to selected UEs in . a cell. : Only UEs that listen to thel • 
correct notification .group can be reached by this procedure. (The initiatiye to send a NOTIFICATION Can come from 
both the access stratum and the non-access stratum. NOTIHCATION can be?sent to either one or wany UEsiat the 
same time. 

[Note: Notification may be. cell specificl , / : ' ' ' ' ' 

[Note: The usage of this procedure is FFS.f . ^ ^' J?" ^ ir.' : v '''•::■''■;•['"' 




8.2 RRC connection establishment aod release procedupes 
8.2.1 RRC Connection Establisiiment - : \ 



UE .. . . , . . . .. . UTRAN : 




RRC CONNECTIOI^.. REQUEST ^ 




RRC CONNECTION SETUP- - 
^ — ^ 




\ Layer Tand layer 2 ^establishment 









Figure 6) Procedure for RRC connection establishment 
This procedure is initiated from the UE side to estiiblish an RRC connection, as a result of either: 
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(1) A request from the non-access stratum to establish the first signaUiiig connection for the UE [Note:^ For a GSM- 
based Core Network some examples of reasons are: CM Establishment Request and Loca}ion Update Request.],, 

or • • " "_' . ' ' ■ ■ . ; ; . ■ ■ ,. . ■ ..■ \ . ■ ' _ . . ,r < 

(2) A received paging request. \Note: Whether the RRC connection is established with or without an explicit request 
from UE non-access stratum in this case is FFS.] 

■me RRC connection establishment is initiated by the UE, which leaves the idle mode and sends an RRC 
CONNECTION REQUEST message using unassured inode on the upUnk CCCH. [Note: Hie initial identification of 
theUE.isFFS.J_x_ ,. j - ' . ./ . : . ■■- - ' .•' ? " : 

As initial identification in flie RRC CONNECTION REQUEST the UE uses a unique Noh access stratum identity. 
This NAS identity could be either TMSI + LAI, P-TMSI + RAI, IMSl or IMEI. [Note: This is pending confirmation 
from WGl that the RACH can support the required payload when this type of ID is used] ■ 

The UTRAN makes an assignment of radio resources mid the Radio Network Temporary Identity (RNTI) to be used by 
the UE.The UTRAN sends an RRC .CONNECTION SETUP message to the UEoising.unassured mode on the 
downlink CCCH. The message included' radio resource pjirameters and the RNTL _ 
The UE configures the layer 2 and layer 1 processing for die DCCH using the radio resource parameters. The 
procedure successfuUy ends when the layer 2 signalUng£l|n>c_i^ estabUshed cm the DCCH. 

[Note- The necessity of an explicit RRC CONNECTION SETUP COMPLETE MESSAGE from the UE to the UTRAN 
on layer 3 is FFS. One assumption is. that there is an explicit layer 2 peer-to-peer signalling to establish the 
signalling link, making an explicit RRC CONNECTION SETUP COMPLETE message on layer 3 unnecessary.] 
Note also that on receipt of an RRC CONNECTION REQUEST message, the RNC can allocate a FAUSCH ch^nel 
for the UE for the particular cell, in which the UE is'cjbipmg on, or FAUSCH channels for a number of cells of, the 
URA, in which die UE is currently stiiying depending on the type of .UE. The FAUSCH channelsallocatal are > 
conveyed to theUE in the RRC CONNECTION SETUP iliessage.The following procedure. which could be used d^ng 
RRG'Coiineaion estabUshmewi is for fiu-ther study: • . • . • . ^ 

Onreceipt of an RRC CONNECTION REQUEST message, the RNC may allocate a dedicated ^^^"^l^o^^^'! 
station. It is also possible to setup macrodiversity at this point. To do so means that the RRC CONNECTION 
REQUEST message must contain a measurement report. In diis case, the RNC executes, branch ^addmoii (physical 
channel activation) to each ceU (/NodeB) that will be included in the active set. After the physical chaiinel(s) are setup 
on the UTRAN side, the RRC CONNECTION SETUP message is sent to die UE on die FACH channel. 



8.2.2 :RRG- Connfebtion Be!eas6 



UE 



UTRAN 



imc CONNECTION RELEASE 



RRC CONNECTION RELEASE 
:a:)MPLETE 



Layer;! aad layer 2 release 



Figure 7) RRC Connection release procedure 

A normal RRC connection release procedure is initiated from the UTRAN, e.g. when the last Signaling Connection is 
released. [Note: Release in case of RRC connection failure is FFS.} [Note: Possibility for UE initiated RRC 

connection release is FFS.] 

Two variants of this procedure have been idenufied: 

a) RRC connection reletise from state where dedicated physical channel is available 

b) RRC connection release from state where diere is no dedicated physical channel 

In die former case (a) the UTRAN sends an RRC CONNECTION RELEASE message to the UE using acknowledged 
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mode on the DCCH. The UE jthen leaves the Connected Mode and initiates release of the layer 2 signalling link The 
RRC Connecuon Release procedure ends when all UE dedicated resources (subhak radiS resources and radio access 
bearers) tied to die RRC connection are released and the RRC layer is tr;msferred to idle mode. 

In the latter case (b) die RRC layer entity in the network issues an RRC CONNECTION RELEASE message using 
unacknowledged mode on the DCCH. Upon reception of this message theUE-RRC sends an RRC CONNECTION 
RELEASE COMPLETE message to UTRAN using acknowledged mode pn th.e DCCH. [Note: Depending onRLC 
design, the acknowledgement to RRC CONNECTION RELEASE could be piggybdcked to the RRC CONNECTION 
RELEASE COMPLETE MESSAGE, resulting in no additional messages. Therefore acked / unacked transmission is 
considered FFS.}. After receiving the RRC CONNECTION RELEASE COMPLETE message the network RRC layer 
releases L2 resources and the RRCentity dedigated to. this UE goes. to Idle Mode.On .receipt of the RRC 
CONNECTION RELEASE COMPLETE message the network releases the FAUSCH channels allocated for the UE 
gomg to idle mode if FAUSCH channels have been allocated during RRC connection establishment. 

8.2.3 - RRC CorineetiDn re-&stablishment . • ^V; o r - 



UE 



UTRAN 



RRC CONNECTION RE-ESTABLISHMENT REQtTEST 



Rpc connectiqn.re-esi;abushment, . 



RRC CQrWEGTIOT^ RE-ESTABLISHMENTGQMPLBIB 



' ' FIgui* 8) WiC Coiinection i-eiestablishmeht ^ ' 3: : ; . ' . . 

RRC connection re-establishment is needed, when a UE losetradio connection due to e.g. radio link failure After ' ~ 
having selected a new ceU, die.UE RRC. sends the NW RRC an^ RRC GONl^CTION-RE-ESj;ABUSiHI4ENr ' " ' 
REQUEST message. The NW RRC configure^' the NW md actaibwiedges the connisction re-e^tabUyimen t to the OE 
RRC with an RRC CONNECTION RE-ESTABUSHMENT message., This message may contain ,the FAUSCH , 
channel(s) vahd for this cell, and possibly other cells of the same URA, if FAUSCH channels have been allocated ' ' 
earher The UE RRC configures the UE LI to activate the new, radio Jink(?).. After the UE has synchronised to at least 
one radio Imk, the MAC and RLC layers can be configured (if h&fesSa^^^^ - ^ '^■'^ >; '.c.r: 

[Note: The necessity of an explicit RRC CONNECTION REESTABUSHMENT COMPLETE message to be sent from- 
the UE to the UTRAN on layer TiflfS: One assumption is, that there is anexpmitli^er 2 peer-to-peer signalling to 
establish the signalling link, makirig^ &cpUcit RRC CONNECTION REESTASUSHMENT COMPLETE message on 
layer 3 unnecessary]. 

8.3 RRC connected mode procedures : 



8.3.1 Radio Access Bearer Related Procedures 



8;3.1.1 



Radio Access Bearer Establishmeht 
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RADIO ACCESS BEARER SETUP 






^v' • ' — .V ' ■/ .. ^ -.: ■• • ' 

ACCESS BEAREk SETUP CbMPUETE 

• ' ■ - - ' ■ — •• » 











( . : Figure 9) Radib Acciess B^are^Establishment 1^ " ; 

This procedure establishes a new radio access bearer. The establishment includes, based on QoS, jissignment of RLC 
parameters, multiplexing priority for the DTCH, scheduling .prioHty for DCH, TFS for DCH and update of TFCS. It 
may also include assignment of a physical channel(s) and change of the used transport channel types / RRC state. 

There are a number of alternative methods by which radio access bearers may be established: 

a) Radio Access Bearer Establishment with Dedicated Physiad Channel Activation 

b) Radio Access Bearer Estabiishment with Unsynehronised Dedicat^ Physical Channel Modifiaition 

c) Radio Access Bearer Establishmen t with Syni^rbnise^^^^ Ghaniiel Modification 

d) Radio Access Bearer Establishnfieiifwiffi^ . .. . . : 

A Radio Access Bearer Establishment is initiated when the RRC layer in the network sends a RADIO ACCESS. 
BEARER SETUP message to its peer entity. This.message conJ^ MAG and RLC parameters and m the \- 
synchronised case an activation time. RRC on the UE side then configures LI and MAC and creates a new RLC enuty 
associated witb^the new radioiaccess bbarer.'K4M^ Hie UE then 

sends a RADIO ACCESS BEAikER SETUP' COMiPLEf iB ihessafee back to the lietwprk; ; / ; ^ 

[Note: the possibil^^^ / - 

8:3:1.2 " ' Radio'Acces^ . .. i' ^1. -r*" : • > . - 



UE 



UTRAN 



RADIO ACCESS BEARER RELEASE 



RADIO ACCESS BEARER RELEASE COMPLETE- 



Figure 10) Radio Access Bearer Release Procedure 



This procedure releases a radio access bearer. The RLG entity for the radio access beiu-er is released. The procedure ^^ 
may also release a DCH, which affects the TFCS. It may include release of physical channel(s) and change of the used 
transport channel types / RRC state. 

The Radio Access Bearer Release procedure is initiated by the RRC layer on die NW side. A RADIO ACCESS 
BEARER RELEASE message is sent from the RRC layer in the network to its peer entity in the UE. This message 
includes possible new LI, MAC and RLC parjuneters for remaining radio access bearers and indentification ofthe 
radio access bearer to be released. [Note: In synchronised case a specific activation time would be needed for the 
. change of LI and L2 configuration to avoid data lossj 
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The RRC on the UE side configures Ul and MAG; 'and releases the RLC entity associated to the released radio access 
bearer . A.sindlar r^onfiguration is a^^ . ^ . . . .. - 

FinaUy, RRC on the UE' side sends a RADIO ACCESS BEARER RELEASE COMPLETE message to the netwbrk. ' 

Currently the following alternative mediiods hive been identified by which Riidio Actfess Bearers may be-releasedV 

a) * Radio Access Bearer Release with unsynchronised dedicated physical chimnel modification- < .; . ' . 

b) Radio Access Bearer Release with , synct^^^^ . . 

c) .Radio Access Beju-er Release - ; ' ' 

[Note: When a radio access bearer carried on a pCH is released, it is FFS, whether the UE should acknowledge the 
RADIO ACCESS BEARER RELEASE message befoie making the feconfigiiratibn '(^^ 
reconfiguration (on the RACH)] ; . . , . . 

[Note: The possibility of releasing multiple radio access bearers \fdthin <)ne message Js FF^l 

8.3.1 .3 Radio Access Bearer and signalling link Reeonfiguratioh - - - ^ ^ 



"uE 




UTRAN 




RADIO ACCESS BEARER RECONHGURATION 








^ 










. RADIO ACCESS BEARER RECONFIGURATION COMI^LETE-,. _ 


1 




— — ~ : : ; , 





Figure 11) Radio Access ^^earer and signalling link R|econfiguratioii Procedure 



This procedure reconfigures parameters for a radio access be^u-er or the signalling link to reflect a change in QoS. It 
may include change of RLC parameters, change of multiplexing priority for DTCH/DCCH, change of DCH scheduUng 
priority, change of TFS for DCH, change of TFCS, assignment or release of physical channel(s) and change of used 
transport channel types. 

Currently identified options^ by which Radio AfccessBeareirs feUf ibeVeconfigured: - ^ * 

a) Synchronised Radio Access Bearer reconfiguration 

b) UnsyAcbronised Radio ACcdss Bearer reconfi^^^ ' sv... 

[Note: mien the reconfiguration involves d change of transport channel (eg, frdm DCH/DCH to RACH/FACH), it is 
FFS, whether the UE should acknowledge the RADIO ACCESS BEARER RECONFIGURATION message before 
making the reconfiguration (eg. on the DCH) or after making ther^configuration\eg.ontheRACHj]_ - " 

[Note: The pdssibility of reconfiguring multiple radio access bearers and signalling' links within one messc^risFFSp 

8.3.2 Transport Channel RecprifjguriatiQri ^ 1 ' 



* UTRAN 




TRANSPORT CHANNEL RECONHGURATION 
< : . 






TRANSPORT CHANNEL RECONFIGURATION COMPLETE. 






. _ ^ 
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, Eigurel2) Procedure fo.r traiwpprt cha , • ' . > . 

This procedure configures parameters related to a transjport chantiel such as the TFS. The procedure also assigns a 
TFCS and max change physical channel paranieters to reflect a reconfiguration of a transport channel ;in use; , ^ 

A change of the transport format set for a transport channel is. triggered in the RRC lay^ in the netv^qrk. A . . \ 
TRANSPORT CHANNEL RECONFIGURATION message is then sent from the RRC layer in the network to its peer 
entity. This message contains thb new. transport format set,- a new transport format combination Set Jind may include 
physical channel parameters, i.e. new par^uneters for LI and MAC. [Notel: In a synchronised procedure a specific 
activation time, is needed fdr the change of LI tmd'Ll configuMtbn to avoid' dhta loss,] When this message is' 
received in die UE a reconfiguration of LI iuid MAC is done. A similar recpnfig^iiration is ^ilso done on the network 
side. FinaUy, a TRANSPORT CHA^mEt RECO^feGURA COMPLETE message is returned to the network. 

CurTeu.tiyid;eiitified^^^.(^^ . . - ^ - 

a) Synchronised transport format set recon£igura:tion ' ' 

b) Unsynchronised transport fonnat set reicbnfig^^ - . > , . 

c) Pre-configua-ationofTFS/TFGS for:atr^^^ v . J ': ' \ ' 

[Note- When the reconfiguration involves a change of transport channel it is FFS. on what channel the UE should 
acknowledge the TRANSPORT CHANNEL RECONFIGURATION message, ie. whether it . should acknowledge before 
making the reconfiguration (eg, on the DCH) or after making the reconfiguration (eg. on the -EACH)] 

[Note: The possibility of reconfiguring multiple transport channels within one message is FFS] 

8.3.3 Transport FornnatCombinatioaJCQntrol ^% 



UE 



-UTRAN 



"TRANSKJRt FOkMATCOMBC^^ CONTOOL 



Figure 13): TraitepoiitfEprm .Gpmbination Cpnt^^^ 



The network uses this procedure to control which transport format, combinations, (within the transpprt fonn^t 
combination set) can be used by the UE in the uplink. An example of when this procedure might be used is when a 
congestion situation/occurs such that it is desirable to temporary^ use, . . _ 

This procedure'^ initiated ^® ' . 

network to the Ue! This message defines the subset of the complete Transport Format Combination Set which die UE 
is;allowed ;to use, or in case of relieving a temporary restriction, a TFCS which is identical to tht complete original set. 
The UE then reconfigures MAC which thereafter uses die new TFC set. The TRANSPORT FORMAT 
COMBINATION CONTROL message may be sent as unacknowledged data transfer (FFS) since it is assumed that it 
does not matter if one UE out of mmy misses this infonriation and stays with the old TFCS. ' ' 
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8.3.4 P hysic'a'l Channel R ecbnf ig uratio.n ' 



UE 



... UTRAN 



, PHYSICAL CHANNEL RECONFIGURE 



PHYSICAL CHANNEL RECONFIGURATION COMPLETE (FFS) 



Figure 14) j^hysjcal thaiinel Recoifflgurati 



This procedure may assign, replace, or release a set of pbysicai channels used by an UE. As a result of tihis, it 'may also ' 
change the used transport channel type (and RRC state). For .exiimple, when the first physical channel is assigned the " 
UE enters the DCH/DCH state. When the last physical chiumel is released the UE leaves the DCH/DCH state and 
enters a state (and transport channel type) indicated by the network: A special case of using this procedure is= to change 
the DL channelization code of a dedicated physical channel. [Note: Tlie procedure does not change the active, s^u in . - 
the downlink the same number of physical channels are added or replaced for each radio link,] 

Currendy identified motivations for using this procedure (methods by which physical channels may be reconfigured): ' 

a) Assignment of dedicated physical channel (switcli'from cokinoti 'Channels to dedicated physic^ channel) ' - V 

b) Synchronised replacement (modification) of dedicated physical channel (eg. for D/L code tree re-organisation) 

c) Release dedicated physical channel (switch: from dedicated physical channel to common channels). 

d) This procedure can also be used to add further FAUSCH channels (e.g. for use iiVdUier cells of the URA, to which 
a UE might move in the future when die UE already has aii .RRGxonnection.) 



8,3.5 Mobility Related Procedures - ^ 

8.3.5.1 Modification of the active set when in Soft hand-over 



UE 



UTRAN 



ACTIVE SET UPDATE ' 



ACnVE SET tfPDATE COMPLETE 



Figure 15) Procedure for modifying the active set when in soft hand-over 



There are three alternative ways of modifying die active set which.haye been identified; - , ; . , , , 

a) Radio link addition , ' " , " . ^ ' 

b) Radio link removal 

c) Combined radio link addition and removal 

Radio link addition is triggered in the network RRC layer. The NW RRC first configures the new radio link. 
Transmission and reception begin immediately. The NW RRC then sends m ACTIVE SET UPDATE message to the 
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UE RRC. The UE RRC configures layer 1 to begin receptiop. After con.finnation from the pbysicaj l^yer in UE an 
ACTIVE SET UPDATE COMPIJBTE message is sentto the W RRC " ' ' " 

Radio link removal is trigga-ed By the network RRC layer. The radio link is first deactivated by the UE and then in the 
NW The NW RRC sends an ACTIVE SET UPDATE message to the UE RRC. Th6 UE RRC requests UE LI to 
terminate reception of the radio link(s) to be raiidved.. After, this the UE RRC acknowledges radio Imk removal with 
an ACTIVE SET UPDATE COMPLETE message-tathe-NW RRQ. The NW RRC proceeds to request the NW LI to 
release the radio link. ; . ■ : . , . 

The NW RRC determines the'need tor raTiio liiik replaceme^^ When radio liiiks are to be replaced, the NW RRC first 
configures the NW LI to activate the radio link(s) that are being added. The NW RRC then sends an ACTIVE SET 
UPDATE message to the UE RRC, which configures the, UE LI to tenninatss reception on die removed radio hnk(s) 
and begin reception on the added nidio iink(s).- If the U£ active set is fiill. fiii old radio link has to be removed before a 
new one can be added. If the UE has only one radio link, then the replacement must be done m reverse order (first 
add then remove). Note: The present assumption is that the order of the replacement can be left to the UE. The UE .■ 
RR6 abldidWledies the replacement Ayith; 

coii'Mgur'estheN;y/ .tl tb't^m . ' . ', 

[Editors note; Presumably the radio link replacement procedure can be. used for intra-frequency(make before break) 

hdrdhand-off] ■. . '•> ■ • ■ - - '^ '' '-' ' ■ , " " 

[Editor's note: TDD active set update will also be supported if the LI group identifies the requirement] 

8.3.5.2 ,..„ : _;Hard handover (Fppand.TP^ ... . 
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Figure 16) Inter^frequency hard handover 

The NW RRC determines the need for inter-frequency hard handover and then configures the NW LI to activate the 
new radio links. The NW LI begins trail smissi on aiid reception oh the new links iminediately. The NW RRC then 
sends the UE RRC a HANDOVER COMMAND message. The message indicates the radio resources that should be 
used for the new radio link, and can include a FAUSCH channel for the new cell, if the UE has not already been 
assigned a valid FAUSCri channel for the new ceil .The UE" RRC configures the UE'Ll to terminate recepuon on the 
old radio link and begin reception on the new radio link. 

After the UE LI has achieved downlink synchronisation on the new frequency, a L2 link is established and the UE 
RRC sends a HANDOVER COMPLETE message to the NW RRC. After the L3 acknowledgement has been received, 
the NW RRC configures the NW LI to terminate reception and transmission on the old radio link. ' 

[Note I: Whether it should be possible to setup several radio links immediately on the new frequency is FFSJ 

[Note 2: The suspension and resuming of the CC and MM signalliiig during handover is FFS.] 
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8.3.5.3 -Inter system hard hand-o\/er (GSM/BSS to UTRAN) 

■ ' ■ " ' - . • / [UTRAN-RRC| 



MS4RR 



UE-RRC 



HANDOVER COMMAND 



VER COMPLETE 



BSS-RR 



Figure 17) Procedure for Inter-system hard hand-over - GSM to UTRAN 

The handover from GSM/BSS to UT^AN for a dualrmqde GSM MS / UMTS UE is desCTibed. • - . .. .. . . 

On the network side, the RRC layer performs admission cpnn-ol and radio resource allocation, assigning an RNTI for 
the RRC connection and selecting radio resource parjimeters (^ transpor^t channel .type] transport format sets, 
etc). * •■ ■■ " " ' - ' • ' ■ 

The selected parameters including the RNTI, aretransmitted to the UE via the upgraded GSM RR message 
HANDOVER COMMAND. Upon reception of the HANDOVER COMMAS message, the UE RRC configures LI 
and L2 using these parameters to locally estabUsh the DCCH logical chjmnel . Layer 1 indicates to RRC when- it has 
reached synchronisation. An RLC signalling link establishment is then initiated by the UE. A HANDOVER 
COMPLETE^. message is finally sent by t^e UE I^C,;./ *v . . ^ . - . ; . - - , . . „ 

8.3.5.4 . Inter system hard hknd-over (UTRAN to GSM/BSS, PSTN/ISDN domain ' 
services) : . ^' " ■ = - ' m 



MS -RK 



UE-RRC 



INTER-SYSTEM HANDOVER COMMAND 



irmA 


N^RRC 




RSS-RR^ ■ 



HANDOVER ACCESS 



PHYSICAL INFORMATION 



HANDOVER COMPLETE 



Figure 18) Inter system hard hand-over (UTRAN to GSM/BSS), PSTN/ISDN services, successful case 

[Note: The scope of this description is restricted to a UE having a connection only to PSTN/ISDN services, i.e. no 
simultaneous IP connection] 
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For PSTN/ISDN domain services UTRAN Inter-System Handover procedure is initiated froni the..lJTRAN. 

The UTRAN RRC sends an INTER-SYSTEM HANDOVER COMMAND (type UTRAN-to-BSS HARD . 
HANDOVER) to the UE to start the execution of the hmidover. This message contains all the infoimation needed for 
the UE to be able to switch to the GSM cell and perform a GSM handover. 

Upon reception of the HANDOVER COMMAND, message, the UE RRC layer can then lociilly release the resources 
on the RLC, MAC and physical layers of the UE. 

After having switched to the assigned GSM channel specified in the INTER-SYSTEM HANDOVER COMMAND, 
the MS RR sends a HANDOVER ACCESS message in successive lay^r 1 frames, just as it typically would have done 
for a conventional GSM. handover initiation. • ~ ' - - ^ ~ 

When the BSS-RR has received the HANDOVER ACCESS it indicates this to the CN/AS by sending a HANDOVER 
DETECT message. The BSS-RR sends a PHYSICAL INFORMATION message to the GSM MS in unacknowledged 
mode that contains various jSelds of physical layer -related information allowing a proper transmission by the MS. 

After layer .1 and layer 2 connections'are successfully established, the bsM MS returns the HANDOVER 
COMPLETE message. 

The UTRAN is then able to release the rbsoufces thfit'were used by the UE in UTRAN Connected Mode. 

If the UE is unable to execute the Inter System Ikiidov^r br if low layer failiire happens on the UE side on d3e 
GSM/SSS channei before HANDOVER COMPLETE has beeii sent, the UE deactivates the new GSM/BSS channel 
and reactivates the UTRAN connection. 

The UE then^sends aiNTER-SYSTEM HANDOVER FAILURE message and resumes normal operation; as if np Inter- 
System Han^dovOTliaMe occurre^^ ; = - ^ :r,. j ; r;; . - , . ^ . ^ : . . i 

8.3.5.5 Inter system cell reselection (UTRAN to GSM/GPRS, IP domain services) 

For IP dom^iiii services, ;infefsystemcdl^ from UTRAN to -GSM/GPRS is initiated.by the'UE,^or ordered by 

the network with the INTER-SYSTEM HANDOVER COMMAND message. • . . ^ ... :. 

8.3.5.6 Inter system cell reselection (GSM/GPRS to UTRAN, IP domain services) 

For IP dolharn seiyic^ intersystem cp reselection from GSM/GPRS to UTRAN is initiated by the UE or by 
GSMTBSSaxxOTd^ 

8.3.5.7 : URA update , A'.a.^.-v.iA:i.';:J--'.:. v' « 



UE : 




UTRAN 




URA UPDATE 










URA UPDATE CONFIRM 






<— 














1 ^ 





Figure 19) URA update procedure. 



The URA update procedure is normally used by the UE to inform the UTRAN that the UE has switched to a new 
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URA. In that case the procedure is triggered after change of cell and after the UE have read information broadcasted 
by UTRAN indicating change of URA. The procedure can also be triggered by expiry of a URA update periodicity 
timer in the UE. 



The UE establishes a radio link to a cell in the new URA. After that the UE sends a URA UPDATE message to the 
UTRAN. Upon reception of the message the UTRAN registers the change of URA, and sends a URA UPDATE 
CONFIRM message to die UE. The URA UPDATE CONFIRM message may include a new C-RNTI and/or S-RNTI 
plus SRNC identity.. In the latter case, the UE trmismits an RNti REALLOCATION COMPLETE message as 
confirmation. The URA UPDATE CONFIRM message may also contain new NAS system information. 

[Note I: Whether it should be possible for the UTRAN to trigger a URA update request from the UE is FFS,] 



8.3.5.8 



Cell update 



UE 



UTRAN 



CELL UPDATE 



CELL UPDATE CONFIRM 




: Figure 20) Cell update procedure. ' 

The cell update procedure is nonnally used by the UE to inform the UTRAN that the UE has switched to anew cell.. In 
this case the procedure is a forward handover procedure, and i^ triggered; fifter change of cell and after the UE has read 
information broadoisted by UTRAN; The procedure can also be triggered by expiry of a cell update periodicity timer 
in the UE or in cases when the UE requests a new C-RNTI. 

In case of cell reselection, the UE abandons the radio link to the old cell and establishes a radio link to the new cell. 
After diat the UE sends a CELL UPDATE message to the UTRAN. Upon reception of the message the UTRAN 
registers any change of cell, and sends a CELL UPDATE CONFIRM message to d3e UE. 

The CELL UPDATE CONFIRM message may include a new C-JiNTI and S-RNTI plus SRNC identity. In.tiiis case 
die UE configures layer 2 to usb'ffie new-tden^^^^ REALLOCATION COMPLETE message as 

confirmation. In the CELL UPDATE CONFIRM message, the network can instruct the UE to start updating its 
location on URA level. It may also contain new NAS system infonnation. 

the cell update procedure can also include the updating of which FAUSCH ch^mhel should be used in the new cell. ' 

In case the UE is assigned a new C-RNTI and/or S-RNTI plus SRNC identity, a RNTI REALLOCATION 
COMPLETE message is sent by the UE to the network. 

[Notel: Whether it should be possible for the UTRAN to trigger a cell update request from the UE is FFSJ 

8.3.5.9 RNTI reallocation . . 
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, UTRAN.' 






. P MTT RF A T J .OCATION 




- 


R MTT RP.A] A OCATION COMPLETE. 

















i . ^ 





Figure 21) RNTI reallocation procedure - 

This procedure is used by the network, to assign new Radio Network Temporju-y Identity (RNTI) information to a UE. 
It is initiated by the UTRAN, whicfi sends a RNTI REALLOCATION message. The RRC message contams new S- 
RNTI and SRNC identity, and/or a new C-RNTL It may also contain new NAS system information. 
The UE starts to use the new identiti^ and returns an RNTI REALLOCATION COMPLETE message Jis 
confirmation. _ : 

8.3.6 RRC Connected mode procedures which use Paging 
8.3.6.1 Core network originated paging 



UE 


- \:. • ■ >• : : ~ . ^ : UTRAN 




' PAGiNdTYPErorTSTE'2(lJNACK) 






y — rr- 




i 



; * . - r Figure 22> Core network. oH^ 

Sofar.only one example of this proc . . .... . ; 

a) UTRAN co-ordinates, UE^^^i^ ' ' ^ . - / . \ 

b) UTRAN co-ordinates, UE is on PCCH (FFS, PAGING TYPE 1 message would be used) 

c) UE co-ordinates (FFS) 

Consider case (a): This procedure enables the CN to request paging of a UE. Since the UE can be reached on the 
DCCH, the RRC layer formats a PAGING TYPE 2 message containing the UE paging identity and the NAS 
information, and the message is transmitted directly to the UE using unacknowledged data transfer. 

[Note: It is FFS whether only one paging message is required (as used for idle mode paging) or whether both Type I 
and Type 2 paging messages are required] 

8.3.6.2 UTRAN originated paging 
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■*UE 



-UTRAN 



/ PAGING TYPE 1 



Cell Update procedure 



Figure 23) UTRAN briginked paging prbcedu^^ ^ ^ 

The RRC layer in the network can use this procedure to trigger a switch from PCH or URA connected state to 
RACH^ACH or RACH+FAUSCH/FACH st£ite. A PAGING TYPE l .message, containing' the S-RNTI and .SRNC 
identity is sent on the PGCH.-^ / - / . j. ; ^ : .r .1. ' ' i n *' 

In the UE, the RRC. layer continuously monitors the paging' group on ' the PdH an (i; compares the IJE identities in the" ' 
received paging messages with its own identities. When a match occurs, tie RRC layer uses the cell update prdcedur6 
to aclmowledge 0e;reception pf paging and optiond^^^ , . - 

[Note: It is FFS whether only only one paging ' message is re(^re<f(as usedjvr idle mode' paging) or whether Type a 
and type 2 pagik^ messages are also requiredf^ ^ ' v .; • 



8.3.7 Procedures related to measurement and monitoring 

/ Note: Hie following text needs to .be reviewed at the next 3 GPP WG2 meeting ] 

In idle mode, the UE monitors and measures neighhjoring cells according to information reeeived on BCH. 

After sending the initial random access message, the UE may continue measurements usiiig the 'idle* mode 
parameters until a MEASUteNffiNT COPTORQt mess^^ serving. RNS. This message indicates 

the parameters to be used for monitoring in "connected^ state. " ■ ■ . 

Monitored cells ^u-e grouped in the UE into three different categories: --^ 

1. Cells that belong to the active seL User mformation is sent from all these cell3 aiid iiby^^W^^^^^ 
demodulated and coherendy combinejj.. These cells are inyoiyed in soft hjmdover . 

2. Cells that are.identified as feasible for hmidover belong to ;the candidate set. The UE;may request; that a cell in ]\ 
the caiididate set is moved to the active set in a MEASURE]VIBOT REP --^ . ■ r • '^i- 



3. Other cells that are k;iown, but not currendy feasible for hmidpver, belong to the neighbour set. The UE does not 
notify the serving RNS when it moves a cell from the caiididiite set to the neighbour set or from the neigihbour set 
to the candidate set. 

From an RRC point of view, the mobile station measurements can be grouped with respect to the type of measurement 
performed in the mobile station, i.e., what and how the mobile station shall measure. Examples are: • 

• Radio link measurements: measurements on downlink radio links in the active set.' ' • . . 
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. Intra-frequency measurem^is:. meiisurements on downUnk physical channels that do not belong to the active set, 
but have the same -frequency as the active set. 

. Inter-frequency measurements: measuremente on downUnk physical channels with frequencies that differ from the 
frequency of the active set. 

. Inter-system measurements: measurements. on downlink physical- channels belonging to another radio access 

system than WCDMA, e.g. PDC or GSM. - ' ..... 

o Traffic volume measurements: nieasurements on uplink fraffic volume. 

A radio link measurement in the mobile station can be used for handover, power control or operation and ^^^^^ 
tZos^^tbc network. However, it should be possible to have a number of mobUe station measurements runmng m 
parallel, where each measurement is controlled imd reported independendy of each other. 

Each tvne of mobile station measurement is associated with a standardised measurement method that can .be desaibed 

Sa todtL Trt^ of p??^^^^^ tfigg-ring conditions etc) in the measurement control message 

from the network. ., . ,■. . : 

The measurement control message W^th^mobUe station, can be sent-using either acknowledged or unacknowledged • 

Ste ^Sr oS LAC Q on the DCCH. The acknowledged mode would be employed for critical control mes^ges. 

TTSZZ^icym^^^..ts intended for handover...The unacknowledged mode may be used fprjess crxdcal 

4asureiiifen^;^:g. mobile mticm ffi^u^ 

The measurement report to d.e network canlikewise be sen-t-fey^ 

in theDCCH. The acknowledged mode may .be employed for e.g. 'if^H JSS^^^^^^ ' 

unacknowledeed mode may be used for e.g. periodical reporung with small periodicity. .The network pan. md^qate 
S=^rt?nTe mobile stati<i measurement control message) which reporting. alternative the mobile stauon should use 
for the corresponding measurement. 

Elementary RRC procedures that are required for UE measurements, and UE measurement reporting to the UTRAN, 
are identified and described below. The procedures are used m connected mode. 

.8.3.7.1 Measurement control _ . ■• . 



UE . 






'4-'" •' 



MEA^SURBVTENT CONTR Oti" • " " 



.UTRAN 











' Figure 24) Meksiirement Control procedure 

This orocedure is mitiated from the UTRAN side to control a measurement in a specific UE. The UTKAN sends a 
I^AS^S^iSJJ^S^mOL message to the UE On^theDCCH. THe message includes the informaUon- that controls 
the UE measurement. Examples of such information are: 

1. Measurement type: One of the types from a predefined list where each type describes what the UE shall measure. 

2. Measurement identity number: A reference number that is used by ^ , ■. 
measuremeiit and by die UE iiu the'measurement report. 

3. Measurement command: One out of diree different measurement commands 
• Setup: Setup a new measurement. , . , .- 

. Modify: Modify a previously specified measurement, e.g. change the reporting criteria. 
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* -Release: Stop a mteasurement ai)d cle^ir all' mfonnatiOri in^the-DE.that are related to tibat measiiretoent ■; • ■ 
Measurement qbjects: "Oie objects .the shall measure on^aind t^^ l' J ; 

Measurement quantity: The quantity the VE shall measure. This jUso includes the filtering of die measu^emetits. 
Measurement reporting criteria: The triggering of the measurement report, e.g. periodical, event-triggered or 
immediate reportog. Here is also specified if the m«isurement report should be transmitted using either 
acknowledged or unacknowledged data transfer on the DCCH. 

[Editor's note: Details ofhojy this proced^e can fPake4iSex>liiUf^e4.m^^, opfraticn if still under investigation. _ 

Measurement reporting 



8.3.7.2 



- - JJE ' ; 











- MEASUREMENT REPORT 



UTRAN 






-> 





Figure 25) Measurement Report pi^bcedure 
^e Measurement ^ort procedure is initiated from the^^E. side when tlie reportiiig criteria.are met. The message is 
Spo^t ^'^kn^l^ed or unacknowledged data transfer "on the DGCA the UE send^ a MEASUREMEOT 

S^menTobfils measurement identity and the measured values of the requested 

[Note: UE measurement reports cariMserit-mhout prior^Measurkmnt Control reports of . h 

fneasurements that are predefined in the standard or defined via system information.] ' • f; , 



\' :f,i.:;:.i 



8.3.8 
8.3.8.1 



Other procedures in connected mode 

Transmission of UE -caipabtl ity Ifitdffflatibn' ^ ^-^^"^ ^ 



UE 



RNC-RRC 



UECAPABIUtYWdRMAtlON' ^ 



UE CAPABILITY INFORMATION CONFIRM 



Figure 26) Procedure for transmission of UE capability information 



mi^eT^7^^^^^ "^l ''"'^^^ traiismittix^g the UE CAPABILITY INFORMATION 

message on the DCCR UTRAN acknowledges the successful update of UE capability by UE CAPABILITY 
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INFORMATION CONFIRM message. Tbis.prcjcedure am (optionally) be performed, after RRG Gonnectipn Setup 
procedure and also during the lifetime of the RRC Connection if the UE capabiUty information changes (e.g. due to 
change in UE power class). UE aipability information aui ^dso expUdtiy be requested by UTRAN'[mte: The * 
mechariismforthis is FFSJ. ; . . 



8.3.8.2*" ' ' Sehdihg of system ihform^^ 



UE 




UTRAN 











UE is In RRC connected mode 



^''SYSTEM INFORMATION 



The UTRAN may send dedicated system informadon messages to the UE in RRC connected mode in order to update 
e.g. neighbouring cell and M]N4 information. The mvBRG/fprwiuds received MM informadon to the UE MM 

sublayer. *, .^v-: . ■\"'z.r- -'t' -.-'v' - . ■.•.r- * ■■ • • 

The system information messages transmitted in connected mode include different combinations of parameters dian 
system information messages for idle mode MSs. The grouping of of system information messages is FFS. 



Three ways have been identified by which this^ag^gl^^ v: 'rV'": 

• OnDCCH 

• On BCCH [Editors noieahe BCCH may be used to convey information to a UE even when a DCCH exists, and 
the current assumption is that vvhere DCH exists BCCH is not used] 

• On CCCH mapped onto a; FACH or a ACCH transport channel (provided the AGCH transport channel exists). 
[Editors note ,the CCCH may be used to convey Jnformation to, a UE even when a DCCH exists]. 
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8.3.8.3 



Direct transfer- 



UE 



UTRAN 



Data request 
from NAS 



DIRECT TRANSFER 



Route NAS 
message to 

correct CN 
domain 



Figure 28) Direct Tranusfer procedure in uplink 

' [ ufRAN ' I 



UE 



DIRECT TRANSFER 



Data request 
'.. trom NA$ 



Route to 
appropriate 
NAS ehfity 



^^^^^^^^^ 



^^igitf e 29) IMirect Ttaiasfer i^dQ^rfe^'^dbMrdink v ? ^ \ 



The direct transfer procedure is used to carry ^ill higher layer (NAS) messages over the radio ihterfacie;^!^ DIRECT^ " 
TRANSFER message includes the higher layer (NAS) message as payload and a CN domain identifier of the 
destination (in uplink) or originating (in downlink) core network node. 

The DIRECT TRANSFER message is used boUi in uplink and in downlink. 

Upon reception of the DIRECT TRANSFER message the higher layer PDU is routed - using the CN domain identifier 
parameter - in UE side to correct higher layer entity and in.inT^AJN sid to correct CN domain.. . - ■ . 



8.3.8.4 RRC status procedure 
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UE 



UTRAN 



-RRC. STATUS 



RRC STATUS ACK 



. ..^mgure 30: RRC status procedure 

[Note: The following descHiksMe htse pfthe RRC status procedure fdryrelease c^^^ connection. Other use of 

this procedure is FFS. J 

If a UE has signalling connections to ckJ and CN2, one of the nodes liiay request die UTRAN to release die RRG 
connection. In diis case die UTRAN needs to inform die corresponding MM entity in die UE - widiout releasing die 
RRC connection - diat die signalling connection has been releiised, usmg die.RRC status procedure. 

When die UTRAN receives a-signallhig- connection release request from a core network node, it informs die UE of a 
signalling connection release widi a RRG STATUS message. After receiving diis message die UE RRC informs die 
corresponding UE MM entity of RRC connection release md sends a RRC STATUS ACK to die UTRAN. When the 
UTRAN receives die acknowledgement message, it confirms the rdease of signalling connecuon to die core network 

node. " " " ' ' — " - - 



9 Primitives between RRC and upper layers . 



10 Message and infomaJ^Qn.e^lam definitiq?i 
and content 

The function of each Radio Resource Control message togedier widi message contents as a list of Information 
elemrats is define4 in sujDclause 1^ . . . . ^ . . - ; ^ - 

The functions of die Information elements are described in subclause 10.2. 

Information elements are marked as eidier M- mandatory, © - Optional or C -conditional. 

10.1 Radio Resource Control messages ^ 

10.1.1 RRC Connection Mobility Messages 
10.1.1.1 ACTIVE SET UPDATE 



<Functional description of this message to he included here> 
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RLC-SAP: t.b.d. ' ^ 

Logical channel: DCCH . . .i . 



Direction: UTRAN -» UE 



Information . 
element. . . 
cateaorv 


Information elernerits 


REFERENCE 


TYPE 


NOTE . V 




MessaigeType 
















UE information 
elements 


Activation, tinrie .. 




o 












PhyCH 

information 

elements 


Primary CCPCH info 




M. . 


Notel- 


For each. radio 
link to add. 










Downlink DPCH info 




M 












Primary CCPCH info 




M 


Note 1 


For each radio 
link to delete 










SSDT indicator . * 




O 























Note J: If it is assumed that primary CCPCH downlink scrambling code is allways allocated with sufficient reuse 
distances^ primary CCPCH fownlink scrambling codewillbe enough for designating, the Jiff e rent radiolinks. 



10.1.1.2 ACTIVE SET UPDATE COMPLETE 

<Functional description of this message to be included here> 

JUX-SAP: t.b.d. - - . _ . .. 

Logical channel: DCCH - • 

. , , Direction:. UE^UTRi^ .1.' ... 1/ 



Informatioiri 
element 
category " 


Information elements 


REFERENCE 


TYPE 


NOTE 




Message. Type 




M 












PhyCH: 
information- •; 
erenhents 


S.SDT indicator 




O 























10.1.1.3 CELL UPDATE 



This message is used by the UE to initiate a cell update procedure. 
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RLC-SAP: t.b.d. 

Logical channel: t.b.d. 
Direction: UE->UTRAN 



Information 
category 


information elements 


REFERENCE 


TYPE 


NO 1 C 




Message Type 




M 












UE information 
elements 


S-RNTI 




M 


FFS.whether in RRC or MAC 
PDU. 


SRNC identity 




M 


Cell update cause 




M 












Meiasurement " 
information- ' 
elements 


Measurement identity number 






Intra-frequency measurement- 
related report (necessity is.FFS) 


Measured results 

























10.1 .1 .4 OELL UPDATE CONFIRIVl - -- - --- ^ 

' ^ ' This message coiifirliis the cell update proceduf e aiid can'bfe used to re^dlocate new RNTIanformation 
for the UE valid in the new cell. 

RLC-SAP: t.b.d: 

Logical ch^mnel: t.b.d. 

Direction: UTRAN->UE 



Information 

element 

category 


information elements 


REFERENCE 


TYPE 


NOTE 




Message Type 




M ^> 












UE information 
elements - .. 


S-RNTI 




M 


FFS whether in RRC or MAC. 
PDU. _ . „. . . . 


SRNC identity - 




M . 


"■ ■ * 1 ' ' ' i 








S-RNTl 




O 


New S-RNTI 


SRNa identity . - . - 




O . 


New.SRNC identity.. 


C-RNT! 




O . - 


New C-RNTI ' 










UTRAN ^ 
mobility 
information- • • 
elements 


U RA update- indicator . . - - 




a.. . , 


When present, it instructs UE to 
make URA updating 










CN Information 
elements 


PLMN identity 




0 


(Note1 ,2) 


CN domain identity 




o 


For each CN domain (Note1,2) 


NAS system Info 




0 


For each CN domain (Note1,2) 





















[Notel: It depends on the length of these information whether this message can be used to notify these information to 

UE.] . - , . 
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. [Note2: Necessity of PLMN is:FFS'and for.CN domain identity and NAS system. infonnation, the confirmation in SA 
WG2 is needed.] 



10.1.1.5'HANDQVERGGMMAND - 

" " '<Functional description of this message to he included here>" 

RLC-SAP: tb.d. 

Logical channel: DCCH . . • . r 

Direction: UTRAN UE , 



information 

element 

category 


Information elements . 


REFERENCE 


TYPE 






Message Type 




M 












Phy CH 

information 

elements 


Frequency info 




M 












UL DPCH power control info 




M 












UL DPCH Info 




M 




Uplink radio 
resQLjrces, • 










ULtimeslot info 




O 












Primary CCPCH info ; ' 




M 


For each -radio ; 
link. Note! 


Downlink radio 
resources 








DL DPCH info " :; 




M 








DL timeslot info j 




O 


Note 2 










SSDT indicator 




o 























! 



Note!: The possibility to request the establishment of several radio links simultaneously with this message is 

FFS. '.. . . , ^. ^ , 

Note 2: It is assumed that the DL timeslot configuration is the same for all radio links, wheth^ or not macro- 
diversity is supported for TDD. 



10,1.1.6 HANDOVER COMPLETE 



<Functional description of this message to be included here> 
RLC-SAP: t.b.d. 
Logical channel: DCCH 
Direction: UE -> UTRAN 
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lnform3tlon 

element 

category 


__ 1 

lnformation,eiements 


Kcr.crtciMwc - 




MOTP ■ ^ ■■■ *■ 








M 












Phy CH 

information 

elements 


SSDT indicator 




o. 























J 



10.1.1.7 INTER-SYSTEM HANDOVER COMMAND 



This message is used for hahdover from UMTS to another system e.g. GSM. One or several messages from the other 
system can be included in the Inter-System tnes^age in fortnad^^^ in this message. These message^s ar6 

structured and coded according to that systemis specification. 

' flLC-SAP:'t.b.d. ' : ~ ~- V' .v. ' ' ' " ' 

- - - Ix)giealchmmel: DGGH , - - - ■ r :'\ 

. .... . .V . -Direction; UTRAN-^XJE -' - r ■ — — ■ : . ;: . • r/-.- 



information 

element 

cateqory 


Inf o.rmatlpn etemeots_ , „ : „ 


B.EFEBENC.E. 


TYPE. 


NOTE.:. 




Messaae-Tvpe- . 




M ■- .: 




■■' ■ , ... _ 








UE information 
elements 


Activation time ; _ . j 




Q 












Other 

information _ 
elements 


lPJ®[:§.Y?l®n!}JI!^.?.^§9® 




M . _. 


















1 



10.1.1.8 INTER-SYSTEM HANDOVER FAILURE 



This message is sent on the RRC connection used before the Inter-System Handover was executed. The 
message indicates that the UE has failed to seize the new channel in the other system. 

RLC-SAP: t.b,d. • " — *' : ' 

Logical chmmel: DCCH 

Direction: UE->UTRAN . . . ^. 
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Information 

element 

caiegory 


Infrtrmntinn Alornonfo t '-• ■ >■ 
iiiiuiiiiciiiijii tslciTlBms 


. :. 


TYPE 

•• - 


NOTE 

■ " 




Message Type - - — . - 




M- 










... . . .... . .... . . . 


UE 

inf ormHtion ■ 
elements 


Inter-System handover failure cause 


" "• - 


O - - 


FFS - 










Other ' 

Information., 
elements 


Inter-System message . . 




o. 























10.1.t;9 URA UPDATE' j " ^ : 

This message is used by the UE to initiate a URA update procedure. 

RLC-SAP:t.b.d. ■ ■ ' ' ■ '■ - '~ ' " ; ' -•■ ' ■■ " 

Logical channel: t.b.d. 
Direction: UE-^UTRAN 



information 

element 

category 


information elements 


REFERENCE 


TYPE 


NOTE 




Message Type > . 




M 












UE information 
elements 


S-RNTI 




M 


FFS whether- in RRC or MAC 
PDU. 


SRNC identity 






URA update cause 




M 























10.1 0 URA aPDATE;BOhtFrRM?^^r- 7 ; 



'<Functiohat description of this message to he included here>lM^ message confirms the URA update 
- . procedure and caii'be used to reallocate new ROTI mfdnnation for the UE- valid after the IJRA~ update. 

• RLC-SAP:xb.d. ■ ' • ' A:l/7 ; '--v' . ... 



Logical channel: 't.b.d. 
•Direction: tJTRAN-!-»UE 




RRC Protocol .Specification 



3Z 



TS 25,331 Y1-1.0 (1999-06) 



Information ' 

element 

category 



UE information 
elements • 



Information elements 



REFERENCE 



Message Type- 



TYPE 



S-RNTl- 



SRNC identity ^ 



S-RNTI 



SRNC Identity" 



C-RNTl 



NOTE- 



M- 



M 



FFS whether InflRG or- MAC:.- 
PDU. ' " - ■ ■ ■■ . 



New S--RNTI 



New SRNC" identity 
New C-RNTI 



CN'information 
elements 



PLMN identity 



(Nbte1,2) 



CN domain identity 



NAS system info 



For each CN domain (Note1,2) 
For each.CN domain (Note1 ,2) 



[Notel: It depends on the length of these information whether this message can be used to notify these infonnation to 

UE.] . ■ . . : ■ ■ • - 

[Note2: Necessity of PLMN is FFS and for CN domain identity and NAS system information, the confirmation in SA 



WG2 is needed.] 



10.1 .1 :1 1 RNTl REAU2OGATIGN- rr 

<FunctionaldescnpkonoftHis~mesmgeto^be^^^ 

' ■ rLC-SAP: t.b.d. ^. - . . - - 

■ Logical .chminel: t.b.d. . — 

ClIT- l" I . DirQQti.on;_lJrRANr^^^ . „ _ ■ - 



Information 

element 

category 



Information elements 



Message Type 



REFERENCE 



TYPE 



NOTE - 



M 



UE information 
elements 



S-RNTI^ 



SRNC identity 



S-RNTl 



SRNC identity 



C-RNTI 



CN information 
elements 



PLMN identity 



CN domain identity 



NAS system info 



FFS whether in RRC or MAC 
PDU. 



New S-RNTI 



New SRNC identity 



New C-RNTI 



(Notel ,2) 



For each CN domain (Notel ,2) 
For each CN domain (Notel ,2) 



[Notel: It depends on the length of these information whether this message can be used to notify these information to 
UE.] 

[Note2: Necessity of PLMN is FFS and for CN domiiin identity and NAS system information, the confirmation in S A 
WG2 is needed.] 
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id;i:;i:i2 RNTrR^^^ ~ . 

™s message is used tocOTfi^^ , . . r; - - 

"RLC-SAP: t.b.d. ■ .;, ' ■- ' ' " , - •;. ; -■ .^—,-...7.. ' 

■' ' " . Logicfil channel: DCCH" ~. • - - - -• ; 

Directioii: UE-^UrkAN • — - - • - — - - . . 



Information 

eiement 

category 


Inf ormiatlori elements - - - 


REFERENCE- 


TYPE • 


NOTE 




Message Type 




M- 















10.1.2 Measure'merit Messages a -: .1:. 

10.1.2.1 MEASUREMENT CONtROL 7. 

<Functioml Uescription of this message to be included here> ^ ' 
Lpgical chaiinel: DCCH _ ' ,^ 
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Information 1 
element- 
category 


nformatlon elements F 


REFERENCE 1 


rvPE r 


40TE 

• 


I 


"ulessage Tvpe 


















Measurement 1 


VIeasurement IdentitV Number- 1 ■ 


- if 


\A 




Information 










elements 


VIeasurernent Command 




\A 
















Measurement Type 


( 


D 












— : , J ^ ; 




Measurement Reportinq Mode 


{ 


D 














1 ■ ' 


Measurement 1 
Object ■ * " " i 


ntra-frequency cell 




2 ■ 


f Measurement Type = Intra 
frequency measurement 


i 


nter-frequencycell 
nfo 




C 


If Measurement Type = Inter 
frequency measurement 


— ,1 


nter-syst&m- cell * " 
nfo ■ ■ - — - ■ 




c ■ 


If Measurement-Type = Inter- 
system measurement 


- - ' 


Traffic volume 

measurement" 

□biect 


- •- 


c 


If Measurement Type = Traffic 
volume measurement - - 




Quality 

measurement 

obiect 




c 


If Measurement Type = Quality 
measurement. 












Measurement 

Quantity 

(Note1) 


Intra-frequency 

measurement 
quantity 




c: ' 


If Measurement Type = intra 
frequency measurement 


Inter-frequency 

measurement;., .-.v 
quantity 




c 


If Measurement Type = Inter . 
frequency measurement 


Inter-system 

measurement 

quantity 




c 


If Measurement Type = Inter 
system measurement 


Traffic volume 
measurement 
quantity 




c 


If. Measurement Type = Traffic 

volume measurement 


Quality 

measurement 

quantity 




c 


If Measurement Type = Quality 
measurement 












Report Ing 

quantity 

(Note2) 


Intra-frequency 
measurement 
reporting quantity 




o 


If Measurement Type = Intra 
frequency measurement 


Inter-frequency 
measurement 
reporting quantity 




o 


If Measurement Type = Inter 
frequency measurement 


Inter-system 
measurement 

reporting quantity 




o 


If Measurement Type = Inter 
system measurement 


Traffic volume 
measurement - 
reporting quantity 




o 


If Measurement Type = Traffic 
volume measurement 


Quality 

measurement 
reporting quantity 




o 


If Measurement Type = Quality 
measurement 










Measurement 
Reporting 
Criteria 
(Note3) 


Intra-frequency 
measurement 
reporting criteria 




c 


It Measurement Type = Intra 
frequency measurement 


Inter-frequency 
measurement 
reporting. criteria 




c 


If Measurement Type = Inter 
frequency measurement 
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inier-sysxern- 

measurement 
reporting criteria 






If Measurement Type = lmer 
system measurement 

*' ■ ■> 


1 raTTic v.oiume 
measurement 
reponing criiena 


- 


c 


If: Meas uremeiit Type =: Traffic 
yolunpe rrieasurement 


Quality ' " 
measurem^erit 
reporting criteria 




Q 


II ivieasurenieni f ype ?= vwuanty • 
measurennent'-f' - , 


Periodical reporting 
criteria 


i 


C 5 















Note 1: Necessary only in event trigger reporting mode. t : ^ ^ ' :• v • 

Note 2: It is FFS whether it is necess^iry to separate the reporting quiintity fdr-each type. 

Note 3: Periodical reporting criteria is used only in periodical reporting modeandi^others iire used in event trigger ' 
mode. , - . . - , . 



10.1.2.2 MEASUREMENT REPORT 

■1 ■ . ' i 
• <Functional description of this message to be included here> - - 

RLC-SAP: tb.d. ^ 

^Logicai' channel:' DCCH ■ ^ / ' " ' " 

' Direction: UE-fUTlRAN • • ^^^^ - • ...... ■ ■^ .\:-^v.- 
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Inforrnati.on . : 
element * 
category 


Informatiph elements . 

■" . 


REFERENCE 


TYPE . 

I :-. 


NOTE 




Message Type 




M ' V 














Measurement 
Information • 
elements 


Measurement Identity Number.. . 




M- ' ■ 




For each 
meas.rep. ; 
in this 
message 
(Note1) 










Event Result 


Intra-frequency 
measurement event- . 
results 




C ' 

r.. 


Necessary only in 
event trigger 
reporting mode 
{Note 2).... 


Inter-frequency _ 

measurement event... 
results 


• - <- - • ~ - 


c • . .: 


Inter-system 
measurement event 
results 




c 


■Traffib volume' 
measurement event 

results^'- " .- ' 




c 


Quality measurement 
event results - 




c 












Measured Results 




o 


Necessary only 
when.indicated> ^, 
optloriallyby 
Reporting Quantity 
in Measurement 
Control 











Note 1: If it is possible to send many measurement results that are identified by dijferent measurement identity,^ 
numbers in the same Measurement Report is FFS. An alternative solution is to admit only one measurement identity 
number per Measurement Report and concatenate different Measurement Reports intheRLC layer instead. 

Note 2: If it is possible to send many measurement results that are identified by different events in the same - 
Measurement Report is FFS, 



10.1.3 Paging and Notification Messages 

10.1,3.1 NOTIFICATION 

<Functional description of this message to be included here> 
RLC-SAP: t.b.d. 
Logical chmmel: PCCH 
Direction: UTRAN UE 



Information 

element 

category 


information elements 


REFERENCE 


TYPE 


NOTE 




Message Type 




M 
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10.1.3.2 PAGING TYPE 1 

This message is used to send information oil the paging channel. One or several UEs, in idl6 of 
connected mode,can be paged in one message, which also can contain other information. \/ 

RLosAP: t.b.d. - • - t:.:: : . 

" Logical channel: PCCH — - J v. ^ ... . 

Direction : UTRAN UE 



Information 
element Category 


RRC Information elerneht 


REFERENCE 


TYPE 


Mote ' 




Message Type 




M 












UE Information 
elements 


Paging record 




M 


One paging record for each UE 
to be paged. 










Other information 
elements 


BCCH modification info 




O 


FFS 





















10.1.3.3 PAGING TYPE2 - 

This message is used to page an UE in- connected mode, when- using tiae-DGGH for CN originated 
paging. 

RLC-SAP: t.b.d, Z r'/^'::'^ ' /\' . ; • i;'- - . j ..; - ' 

Logictil channel: DCCH 

Direction: UTRAN XJE, . , , , _ 



Information 
element Category 


RRC Information element 


REFERENCE 


TYPE 






Message Type 




M . 












UE Information 
elements 


CN domain identity 




M 












Paging cause' V r.^ 




M- 































1 0. 1 .4 RRC Connection Establishment and niaintenance messages ' ' ' ' • 

10.1 .4:1 RRC CONNECTION RE-ESTABLISHMENT " 

<Functional description of this message to be Included here> ' 
RLC-SAP: t,b.d. 
. . . Logical channel: t.b.d. 

Direction: UTRAN UE 
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Information 
element 
category ' 



Information elements 



REFERENCE 



TYPE 



NOTE 



Message Type 



M 



10.1.4.2 RRC CONNECTION RE-ESTABLISHMENT COMPLETE 

, ■<Functtonal4escrij)tLon of^^ 

- RLG'SAPM:b;d; -yy^---- - — . , 

....... ^. . . . Logical- chiii»iel: DCCH - — - - - " 

Dkection: IJE -^UTRAli ■ ..: • 



Information „ 

element 
category 



Inforcngtion elements 



Message Type 



REFERENCE. 



TYPE 



M 



NOTE 



10.1.4.3 RRC CONNECTION RE-ESTABLISHMENT REQUEST 

<Functional description of this message to be included here> ' ^ - 
RLC-SAP: tb.d. 

Logical chanuel: Bid ' I ' " " ; 
-.JDirectian:UE.^..imiAN.--^ --J— - - — 



inforrnation, 

element 

category 



Message Type 



UE Information 
elements 



Measurement 

information 

elements 



I nf ormat ion elements 



S-RNTl 



SRNC identity 



REFERENCE 



TYPE 



Measurement identity number 



Measured results 



NOTE 



M 



M 



M 



M 



M 



FFS whether conveyed on RRC 
or MAC. 



Refers to system 
information. . 
Notet ' 



For each 

measurement 

report 



Note 1: The necessity mid usage of Measurement identity number in this message is FFS. 
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10.1.4.4.RRC CONNECTION RELE.ASE • - 

- <^^^^^^^i^nal description.ofthisMes^^ included hero 

' " ' RLOSAP: t.b,d, /" "7" . ,^ " ^ - • 



Information 
element 


Information eiementis 


REFEftENCE 


TYPE 


NOTE 


categorv 












Message Type 




M. 




UE Information 
elements 


Release cause 




M 














Number of Quick Repeat 




M ' - 





10.1.4.5 RRC CONNECTION RELEASE COMPLETE ■ 

<Functional description of this message to be included hero 
RLC-S AP: t.b,d. 
Logical channel: DCCH 
Direction: UE UTRAN 



Information 

element 

category 


Information elements 


REFERENCE 


TYPE 


NOTE 




Message Type 




M 





10.1.4.6 RRC CONNECTION REQUEST 

RRC Connection Request is the first message transmitted by the UE when setting 
Connection to the network. 

RLC'SAP: t.b.d. 

Logical channel: CCCH 

Direction: UE ~» UTRAN 
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Information 
element- 
category 


Information elements 


REFERENCE 

- 


TYPE 


NOTE 




Message Type 




M' 












UE information 
elements 


Initial UE identity 




M 


FFS whether conveyed on RRC- 
or MAG. ^ 










Establishnnent cause 




M 












Initial UE capability 




o - ^ 


Necessity is- FFS ■ 










Measurement 

information 

elements 


Measurement identity number 




M - ' 


Refers to system 
information. 
Note 1 


For each 

measurement 

report 


Measured results ^ 




M . - . 

























Note l:..The.necessity.and~usage.of Measuremeait4dentityiium in this message is FFS. 



1 0. 1 .4.7 RRC CONNECTION SETUP ^ 



This message is used by the network to accept the establishment of an RRC connection for an UE, 
including assignment of signalling link information, transport chmmel information and optionally 
physical channel information. ' ~ ^ > " " • 

RLC-SAP: t.b.d. ...v., ..^ " . • . ' ■ ^ ■ 

Logical channel: CCCH ' . r - 

Direction: UTRAN ~» UE . * • \ 
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Information 

element 

category 


Information elements 


REFERENCE 


TYPE 


NOTE - ' 




Message Type 




M . 












UE information 
elements 


Initial UEjdentlty ---^ - - 




M- . 

' • --^ 


FFS whether conveyed -on RRC 
or mAc. " ' - * " • ' ^ 










S..RNTI . .... 




M .... 




SRNC.-identity - - . 




M 




C-RNTI - - 




D 


Only, if .assigned to a common 
trahsjDbrt' channel' " ^ ' • 


Activation -time ^ ^ ... . ... ... ^. 




O ..^ 




. . . 








RAB 

information . 
elements. 


RAB identity 




M 


Indtcates the signalling link 











Signalling link. type . 


_ , _ 


M 


2 i « 


™ . . 








RAB multiplexing info 




M.. ^ 


Forthe signalling link„ . . 










TrCH 

information 
elements 


TFCS 




O 


Uplink TFCS 










TFCS 




O 


Downlink TFCS 










TFC subset 




o 












Transport channel identity 




M 


For each new • 
transport 
channel - 


Uplink 

transport 

channels 


TFS 














Transport channel identity 




M - 


For each new 
transport 
channel . 


Downlink 
ti'ansport 
channels 


TFS 




M 
















PhyCH 

information . .. 
elements 


Frequency info 




O 




„ _ 








Uplink DPCH power contrbl'info - 




O = 












Uplink. DPCH info 


» 


Q..„ 


Maximum, one 1 

of; these;.:', i-..: 


Uplink ra9ift'?5J 
resources 


PRACH info 




D.., 


UplinkilmeslDt info^, , , . . 




.O. .... 






_ 






Primary-.CCP.CH info:. 




O 


For .each radio 
link 


Downlink radi.o, 
resources ^ : 


-Downlink DPCH- infci , 




o . 


Secondary CCPCH info 




o 


Downlink timeslot info 




o 


Note 1 










SSDT Indicator 




o 


Necessity is FFS 










Gated Transmission Control info 




o 


FFS 





















Note 1: It is assumed that the DL timeslot conjQguration is the same for all radio links, whether or not macro-diversity 
is supported for TDD. 



10.1.4.8 RRC CONNECTION-REJECT 

This message is transmitted by the network when the requested RRC connection caimot be accepted. 
RLC-SAP: t.b.d. 
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Logiad channel: CCCH 
Direction: UTRAN UE ^ 



Information 

element 
catei^bry 


Information elements 


REFERENCE 


TYPE 


NOTE 




Message'Type 
















:UE informatlonr. 
elements 


Initial y.E-identity 




M 


FFS whether conveyed on RRC 
or MAC.:;. 










Rejection .cause ' '"'"* 




M • 












Wait'time ' ■ 


















1 : ^ . ■« ■ 









10.1.4.9 RRG STATUS;; " 1 7Z^.^'' ^^.^^L^ ' '. . '. 7 '",; • ; . 

, - This message is transmitted by .the uetwork.when the network requests .UE„to release one of several 

• sign billing coiiriections.- — _ J". " . ; 

.-::i::RLC-SAP:a:bii.?..: .... . - " ...... . 

; Logical chiirineh DCCH - - - J: „ r:-: -.i:. 

•\. VVj IlJ rZ " L. „ . " Jl . . 



Tnfbifmatibri 
element 

categpryfn^. i 


Irifbrmatrdn eilemenfs " 

j 


reference; 




NOTE:"" 


J. 


Message-Tiypei r ! '■ 




M' 


... . ■ ■ • . - *-*' 










CN information 

elements': 


CN cfomaih identity ' ' 



























1 0. 1 .4:1 Q RRC STATUS ACK 



-This message-is transmitted by- UE as iui acknowledgement for RRC STATUS .message 

- 'ij- '-■ .'■RLC-SAJP:-t:b.d.- ' ''"^^"'r'T^ --^ \ ' 1 ■ " ' ' 

Logiciil channel: DCCH 
Direction: UE UTRAN 
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Information 

element 

category 


Information elements 


REFERENCE 


TYPE 


NOTE 




Message Type 




M . 























10.1.5 Radio Access Bearer control messages 

10.1.5.1 PHYiSreALChlANNELREGONHrGUBATION . . . - - - :. - 

This message is used by UTRAN to-assign, replace or release a set of physical channels used by a UE. 

RLC-SAP: tixd. - - ■ . ; • i.:: • ■ \ '' 



Logical Ghiinnel: DCGH 
Direction: UTRAN UE 



Information 

element 

category 


Information elements 


REFERENCE 


TYPE 


NOTE 




Message Type ' ' 




M 












UE Information 
elements 


Activation time 




O 




C-RNTI 




O 


Only RACH/FACH 










UTRAN 
mobility 
Information 
elements 


URA update indicator 




o 


When PChj shall be used, and 
when presentrit instructs the 

UE to. make URA updating 










PhyCH 

information 

elements 


Uplinl< DPCH power control info 




o 












Frequency Info 




o 












Uplink DPCH info 




o 


Maximum one 
of these 


Uplink radio 
resources 


PRACH info 




o 


Uplink time slot info 




o 












Primary CCPCH info 




o 


For each radio 


Downlink radio 
resources 


Downlink DPCH info 




o 


link 




Secondary CCPCH info 




o 


For FACH 




Secondary CCPCH info 




o 


For PCH 


Downlink timeslot info 




o 


Note 1 










SSDT indicator 




o 


Necessity is FFS 










Gated Transmission Control info 




o 


FFS 





















Note 1 : It is assumed that the DL timeslot contiguration is the same for ail radio links, whether or not macro- 
diversity is supported for TDD. 
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10.1,5.2.PHYSICALCHANNEL RECO NRG U RATION COMPLETE.. .- , ' • 

V This messageis seiU#om tlie.UEwJien aphysiaachamie^ 

' RLC-SAP: Lb.d. ' - 

Logical chainiel: DCCH 

Direction: UE UTRAN j . ^, . . • • - „ 



Information 
element 

category 


Information elements * ' 


REFEReNCE 


TYPE 






Message Type 




M 








0 


Necessity is FFS 


Phy CH 

information 

elements 


SSDT indicator 









10.1.5.3 RADIO ACCESS BEARER RECONFIGU 



- This message is sent from XJITlAN-tOTeconfigure parameters rel^^^ to a change of QoS. This . 

- • procedurecairidso(±iaiige'biemultipiexingof^ 

;~ channels." - - - — : ; " i - 
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Information 

element" 

category 


Information elements 


REFERENCE 


TYPE 


- . . . . - 




Message.Type: . 
















UE Information 
elements 


Activation- time: > 




o 




C-RNTI 






Only RACH/FACH 


- ' '* ' 








RAB 

information 
elements 


■ RAB identity . 




M 




• For each RAB 


RLC info" : 




o 


FFS 


affected by this 


RAB multiplexinq info 


:■ 


M 




message 


■- .: r ■ 


, . _ 








TrCH 

information 
elerneots 


TFCS _ 


. 


.o 


tor uplink QCFis' „ . ... 










TFCS, . . . . _ 


-~~ 


o..„ . 


for downJink DCHs ' '-f- 










TFC subset ._. ...... 




Q. „ . 


for. DCHs in uplink 












Transport channel identity , 

- '■■ - 


— 


.O. 


For each 

removed • / : 
transport ; .;. ■ 
channel 


Uplink 
transport 
channels - 


Transport channel identity 




O .r. 


For each:/ 
reconfigured or 
abided , - 
tr^ahsport . . 
channel 


■ r r 








TFS- 


i 


f ,- • 


Dynamic Gontrol 




o ^ 


For each" r^^'c 
fecohfigufed or 
added . ' ;■ 
traiisport"- " • 

channel - 

CQntrolled by - 
DRAG 


Transmission tiiiie validity 
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Time durs^tion before retry - ' 
Silent -period duration before release 



Transport, channel identity 



Ph'yCH 
i'nfo'rmatidh 
eierfTents" " 



Tranpsort channel identity 



TFS 



Uplink DPCH jjower control mTd' 



info 



Qplihk DPCH info 



For each.:: . J. 
rempyed. . .... 

transport /j. j 
channel ' 



For each 
reconfigured or 
added' . 
transport ^ 
channel' 



.Uplink tlnneslot info 



Primary GCPCH info j. 



Downlink DPCH info 



SecondaryX'GPCH info 



Downlink timesl'ot info 



SSDT indicator 



f^satfid Trarishrtission Control info 



Downlink 
transport, 
channels 



MaxirriUrti one" 
of these:;,.. ' 



Uplink radio 
resources 



Fp.r.each:Fadia 
link " ■" " 



Note 1 



Downlink radio 
resources 



Necessity is FFS 



FFS" 



Note 1 : It i3 assumed that the DL timeslot configuration is the same for all radio links, whether or not m^cro- 
; diversity is supported for TDD. . ; 



loJl .5.4 RADIO ACCESS BEARER RECONRGURATION COMPLETE 

This message is sent from the UE when a RAB and sign^illing link reconfiguration has been done. 
RLC-SAP: t.b.d. 
Logical chainiel: DCCH 
Direction: UE UTRAN ' 
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Information 

element 

category 



Information elements - 



RAB 

information 
elements ' 
TrCH ; 



information 
elements 



"Message Type 



RAB idehtitv" 



REFERENCE 



TYRE 



M 



NOTE. : . 



M 



Transport cha:hhe! rdentity* 



o ■ 



For each reconfigurecTRAB ' 



For each removed, ; 7 . ' 
reconfigured or addec^ transport 
channel" ' ' ■ . .. . ' 



PhyCH • 
Information- 
elements 



SSDT indicator 



Necessity is FFS 



10J .5.5 RADIO ACCESS BEARER . RELEASE I 

^ . <Functional description of this message to be included here> 
RLC-SAP: tJbZ ~: :.: :. ; 
Logical channel: DCCH ' . 
Direction: UTRAN;-^ UE 
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iiii or mciiiijii 

element 
category 


irii oriiioiiuii tsitsiiici lid 't-^.- .-4 

• 


REFERENCE 


TYPE 

1 I r C 


NOTE * •• . - ■ ' " ;« . 

INw 1 C ■ ■ 

: . 




Message Type 




M 












UE Information 
elements 


Activation.time ' i 




Q 




C-RNTI 




O 


Only RACH/FACH"'-- 










RAB 

information 

.elements 


R/SR iHonfi+w ' 
r\r\D luolliuy 




M • 


















Por Qpr^h othor RAR affont&H K\/ 

thismes^iaae- - 


RAB rriultible'xina Info^ 




o . 












TrCH 

information - 
elements 


JfQS - ■ - — 






for uolink- DCHs ■ - 










TFCS 




o 


for downlink DCHs 










TFC subset 




0 


for DCHs in-uplink 










; . 

Transport channel identity 




O 


For each 
removed 

transport 
channel 


Uplink 

transport 

channels 

♦ 


Transport channel identity 




o 


For each : 
reconfigured or 
added. (FFS)J.,. 
transport • 
channel ' ■ 


TFS 




o 


Dynamic Control 




0 


For each 
reconfigured or 
added (FFS) 
transport 
channel, 
controlled by 
DRAC 


Transmission time validity 




o 


Time duration before retry 




o 


Silent period duration before release 




o 










. . 

Transport channel identity 






For each 
removed 

transport 
channel 


Downlink 
transport 
channels 


Transport channel identity 




o 


For each 
reconfigured or 
added 
transport 
channel 


TFS 




o 










PhyCH 

information 

elements 


1 lolink nPf^W nn\A/p>r r*nritrril Info 




n 












Pr(^niA^r\c\/ info 




o 












Unlink DPCH info 




o 


Maximum one 
of these 


Uplink radio 
resources 


PRACH info 




0 


I Jnlink timeslot info 




0 












Primary CCPCH info 




o 


For each radio 
link 


Downlink radio 
resources 


Downlink DPCH info 




o 


Secondary CCPCH info 




o 


Downlink timeslot info 




o 


Note 1 
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Note 1 : It is assumed that the DL timeslot configuration is the sjime for all radio links; whether or hot macro- 
diversity is supported foTTDD. . , . 



1 0. 1 .5.6 RADIO access; BEARER RELEASE COMPLETE 

- KFunciiondldescfiptidri of this message to be TncVuded he fe> 
•■ RLC-SAP:t.b.d. , ■ " " " 

Logical channel: DCCH - • — . 

Direction: UE --^ TZFRAN- - - - - - ; 



Information .„ 

elenienjt 

category 


Information elements 


.BEF^EREMCE 


TYPE 


NOTE . 




Message Type . 




M 












BAB . . . 

information 

elements 


RAB identity _ . . _ 




M 


For each released RAB 










TrCH ' 

information 

elements 


Transport channel identity 




O 


For each removed, 

recpnf igured or added transport 

channel ^ 





















10.1.5.7 RADIO ACCESS BEARER SETUP 7 ; 



<Functional description of this message to be included here> 

. -,- . ' . ■ .. ' . *■ ,■ 

: LogiaU GhcUinelirPC^ 
Direction: IJiniAN ^ UE ; 
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Information 1 

element 

category 


nf orrnation elemerits R 


EFERcNUc J 

N 




ftTP 1 

J '•*■«. * ' . . • - 1 


N 


/lessaqe Tvpe 








CN Information h 
elennents 


JAS binding info 


N 


/I 1 
s 

jl 


'ransparent non access 
tratum info e.g. bearer . 
dentity. | - 


UE information / 


Activation time 


C 






elements C 


>RNT1 ■• 


• .• • ( 


D ' C 


Dnly RAGH/FACH- 


RAB F 


RAB identity 




J\ F 


-or the new RAB 1 


information F 
elements F 


mc info 

=IAB multiplexing info 


I 
[ 




f 

1 I 
TrCH 

information 


=1AB identity 

RAB multiplexina info 

ri^cs *' / • 


( 
( 


D f 
D t 

D 1 


=or each other RAB affected by 
his message 

or uplink DCHs 


elements 


TFCS 

TFC subset 

Transport channel identity 


;• - ■• 


0 1 

o 
u 


or downlink V^r 

for DCHs in uplir 

For each I 
removed t 

transport ' t 
channel 


is ' o 
k 

Jplink ; • | 
ransport • -J \ 
channels ' 


Transport channel identity 




o 


For each 

Veconfigured or 
added 
transport 
channel 


= 


TFS • , 


• „ ..... 

. . .1 _ . . 


o ^ 


Dynamic Control 




o 


For each 

reconfigured or 

added 

transport 

channel, 

controlledby 

DRAC 


Transmission time validity 




O : 


Time duration before retry 






Silent period duration before release 




o 


Transport channel identity 




o 


For each 
r'emdved (FFS) 
transport 
channel 


Downlink 1 

transport 

channels 


Transport channel identity 




o 


For each 


TFS . 




0 


reconfigured or 
added 
transport 
channel 






D 




PhyCH 

information 

elements 


Uplink DPCH power control info 




KJ 




Frequency Info 


















Uplink DPCH info 




n 


Maximum one 


Uplink radio 
resources 


PRACH info 




n 


of these 


Uplink timeslot info 




\j 
















Primary CCPCH info 




O 


For each radio 


Downlink radio 
resources 


Downlink DPCH info 




O 


link 


Secondary CCPCH info 




o 




. Downlink timeslot info 




o 


Note 1 
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SSDT indicator 



Gated Transmission Control info 



Necessity is FFS 



FFS 



macro- 



1 a 1.5.8 RADIO. AGCESSiBEARER SETURCQ^^ 

' ^■<Functional descHptionJf this mmagejo. bkii^udkd 
RLC-SAP: t.b.d. . \ 
Logical channel: DCCH ' " 
Direction: UE>^ UTT6\N: ""V ' ~ ' :;v : 



Information 
element 
category - ; 



RAB 

information 
elements 



JrCH. 

information 

eleniehtsr- 



Phy CH 
information' 
elements r. 



information elements 



Message. Type' 



RAB identitv 



REFERENCE 



TYPE 

• ? i . . . 



M 



Transport .channel identity 



SSDT indicator 



M 



NOTE 



For.each new. RAB 



For eac h rern oved, • ^ - 
reconfigured ^? added transport 

channel.^ , 



Necessity IsiFffS 



1 0. 1 .5.9 TRANSPORT 'channel R 



This piessage^ used by UTRAN to configiy-e the mm i^eiudes a 

possible reconfiguration of physical channels. The.message can also be used, to assii^n a TTC subset 
and reconfigure physical chfmnel. 

RLC-SAP: t.b.di . • ^ . . , , ■. ; . • : ' 

Logical (Channel: DCCH 

Direction: UTRAN UE " • ' ' : 
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Inf ormatloD elements 



TYPE. NOTE 



Messacje Type 



Activation time 



Control-oniy-state-timer 



TFC subset - '•• 

Transport channel identity 



Only RACH/FACH 



foruplinR-DCHs' 
for downlink DCHs 
for PCHs in uplink 



Dynamic Control . . 

Transmission time vaiiditv 

Time duration before retry 

Silent period duration before release 



Transport channel identity 



Oyiirik PPCH "power cohtrbl info 

Frequency.'info-' : ■ 

Uplink QPpH^mfo - 

PRAQHinfo ; -i - 

QplMJM^sFbf info./ 

P.rimary. caPCIri-info — ' 

Downlink QP-CH into ' 

Secondary CCPCH info 

Downlink timesiot info 

SSDT indicator 

Gated Transmission Control info 



Necessity is FFS 



Note l: It is assumed that the DL thneslot configuration is the same for all radio Unks. ,wheti.er or not macro-diversity 
is supported for TDD. 

10.1.5.10 TRANSPORT CHANNEL RECONFIGURATION COMPLETE. 

This message is sent from the UE when a transport channel reconfiguration has been done. 
RLC-SAP: t.b.d. 
Logical channel: DCCH 
Direction: UE UTRAN 
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Information 

element 

category 



TrCH 

information 
elements . 



Phy CH 
information 
elements . 



Information elements 



Message ty pe' 



Transport ch&nilel ic^ehtity 



SSDT indicator 



REFERENCE 



TYPE 



M 



M 



NOTE 



Foi- each reconfigured transport 
chariTiei:;' ' 



Necessity is FFS 



Note: The usage^of this messagefor indicating the cell the UE will select in the DCH->RACH/FACH 



case, is FFS. 



10.1.5.11 



TRANSPORT FORMAT COMBINATION CONTROL 

<Functidhdl descnption of this message to be included here> 

RLCrSAP:xb.d. .V" . ..'I* i \ S\ "'.1. ' ''i-^V" 

. Direction: UTRAN^UE " ~ " , . ~ z ' ' 



Information 

element 

category 



TrCH 

information 
elemehfs 



Information elements 



Message Typ e 



TFC subset" 



REFERENCE 



TYPE 



M 



M 



NOTE 



for DGHs'in>UL 



10.1 .6 System Information Messages 
10.1.6.1 SYSTEM INFORMATION 

<Functional descnption of this message to be included hero 
-RLC-SAP: t.b.d. 

Logical channel: BCCH or DCCH or CCCH 
Direction: UTRAN -> UE 



NOTE: The division of the system information into messages is FFS. 
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Information 

element 

category 


Inlormatlon elements ... - .. - 


REFERENCE 


TYPE 


NOTE - - 




Message Type . - - 










- — " ... . ^ 






CN information 
eleniehts- 


R.LMN Identity - 




^ M.. 




GN dorWain identity ' 








For each Core' 
Network' ' ' [ ' 
Domain^v' " 

Information" 
must be "■ iV 
included for at . 
least one core 
network 
domain type. 


NAS systenri'mformation- — - 

■ — — ■ 

■' ■■ ■'■ - " f- 


- - - - - — 


...M- 

- 












UTRAN 
mobility 
information 
elements 


URA identity 




M 




For each URA 


Information for periodic cell and 
URA update . 7 - ^ - !. 




M 




Note: not for 

each URA any 
more 


Geil identity . 




M 


The necessity and usage of 
cell identity is FFS. 


Cell selection and re-selection info 




M 












UE 

1 n f nriTi ft ti nn 

elements 


Uplink access control info 




M . 












Transmission probability 




O' 


For. air UE . 
having DCH 
controlled by 

DRAC„. 

procedure * 


For each class * 

of UE - *r 

Note2 


Maximum bit rate 

, . . , . . ^_ 


- - . 


0 










PhyCH 

infonnation _ . 
elements^. — 


Frequency info 






For each RACH . _ . 


PRAGH info 




M 












Freqeiervcy 'mi6 Jj ^' 




0 


For each- FACH on secondary 
CCPCH 


Secondary CCPCH info 




M 










Frequency info J 




0. 


For.each..PCH.on secondary ~ 
CCPCH 


Secondary CCPGH info 




M 










PRACH power control info 




M 
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Measurement ' 

Information 

elements 








iNoje. I . . 


For each".lntraT« 
frequency . 
measurenrieht 
control ^ ' 










Intra-frequency cell info 




M 


For each 
measurement 

^ *^-f - 











inira-TreCjUericy measuremeni 

m-iantltv/ 




1 Vi 










• •>. . .- • ' 


1 rjf ra-f roni icinr^x/ mdaciirttmont - - ■ 

repertmg criteria — 


• 




V- c'" ... 










ivieasHjrenrieni laeniiiy iNumDer 




- M - 


Note -I — 


For each4^ter-"- 
frequency- 

measurement 
control 










Inter-frequency cell info 




M 


For each 
measurement 










ini6r*ircqucncy rneasurornenx 
niiantitv/ 




Ivl 












I ntpr-f rpniipnpv mpfl^iirpmpnt ' **■ 

reporting criteria 


t '. I-* 


• - . IVI 












tvieasuremenT tueniiiy iNUmuer 




Ivl 


NOie I 


For each Inter- 
system 
measurement 
control 










Inter-system cell info 




M 


For each 

m eas u re m ent 

object 






'. 'i . 




Inter-system measurement 




^ A 
M 












Inter-system measurement 

reporting.c.riteria „ _ . 




M 

























Note 1 : . The necessity .^ipd usage g.f Measurement 

Note 2: The split of parameters into sever£d"^Systeni M is FFS. 



10.1.7 Other Messages 



1 0. 1 .7. 1 UE CAPABILITY INFORMATION 

<Functional description of this message to be included here> 
RLC-SAP: t.b.d. 
Logical channel: DCCH 
Direction: UE UTRAN 
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Inf nriiria'tion ' 


information. i4lements ■ 


REFERENCE 


TYPE 


NOTE - ' : - -^-^^ 


element 










category' 


• • ! r 










Messaae Tvds 




M 












UE information 
elements 

i 


Power eontro^- caoabilitv 




M" - 




Onrie resource canabilitv 


• 


M " 




UE"mode' capability ~ ' " ' 




M 




Transport"CH support ^capability' 


. . „ 


o- ■ • H 




Ciphering capability 




M ' ^ 




Macro" diversity capability " 




M - 






' ' " . . 





















Note: The WG l mid W.G4 discussion should be concluded before die contents of this message can be 
finalized. ' ^ - ■ - • - " 



1 0. 1 .7.2 UE CAPABfUTY INFdRMATiON CONFIRM 



^Functional description of this messageAa .b'€i.includeci.here:>^ . 
REC-SAP: t:b.d^^ - [ ] • 

Logical channel: DCCH _ 

Direction: UTJ^N A UB _ , 



Information 
efement]_ _ 
category 


Information elements _ 


REFERENCE 


TYPE 


NOTE ' - 




Message Type 




M 























10.1.7.3 DIRECT TRANSFER 

<Functional description of this message to be included hero • •. \ . . ' 
RLC-SAP: t.b.d. 
Logiad channel: DCCH 
Direction: both 
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Inf orrnation 

element 

category 


information elennents . • . 


REFERENCE . 


TYPE, 


NOTE , t ;. ' . 




Message Type 




M ,-,{ 












CN Information 
elements 


. — . , — 

CN domain identity 




M 












NAS message 




M-' ■ 
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' 1 0.2Tlhfarmati6n felem definitions ^ ' ' . ' 

10.2.1 ClSI. InforTOatlon "eiemeb^^ . - - - •• i 

10.2.1.1 CN domain identity ' ■ '"' '"• 

Points out the core hetwork'ddmMH^^ 1/ ^ . •- 

10.2^1.2 NAS-blnding-info '■ - - - •'■ - • ' 

A field with non-access stratum information to bind a RAB to the non-access stratum. This information is transparent 
toRRC. 

1 0.2. 1 .3 NAS message 

A non-access stratum message to be tfansferred transparently through UTRAN. 

10.2.1.4 NAS system information 

System information that belongs to the non-access stratum (e.g. LAC, RA code etc). This information is transparent to 
RRC. 

10.2.1.5 PLMN identity 



Parameters 


REFERENCE 


TYPE 


NOTE 


MCC, Mobile Country Code 




M 




MNC, Mobile Network Code 




M 





10.2.2 UTRAN mobility Information elements 

10.2.2.1 Cell identity 

Identity of a cell within a PLMN. 

Note: The necessity and usage of this information element is FFS. 

1 0.2.2.2 Cell selection and re-selection info 



Parameters 


REFERENCE 


TYPE 


NOTE 


Standby allowed reception level (dBm) 




M 




The usage of 
these 

parameters 
needs 
clarification 
FFS. 


Standby prohibited reception level 
(dBm) 




M 






Threshold for Cell Re-selection (dB) 




M 






Allowed reception SIR (dB) 




M 






Radio link timeout 
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1 0.2.2:3- Information for periodie ce^^ update^ 

•■FFS. ' ' ■ . , 

10:2.2 AURA. identity.; I lu./ : . • ; t V 
Identity of the UTRAN Registration Area. 



10.2.2.5 URA update indicator 

When present in a message, it instructs the UE to start to update its location on URA level. 



10.2.3 UE Informatipn^elenrients, 
10.2.3.1 Uplink access control info 



Parameters 


REFERENCE 


TYPE 


NOTE 


Access class ... 




M 


FFS . ... 


Dynamic persistence level 




M ' 


FFS 



10.2.3.2 C-RNTI 

The controlling RNC RNTI identifies an UE having a RRG eimnection within an controlline RNC- • 

10.2.3.3 S-RNTI •■■-•■v rvr y, ,, 
The serving RNC RNTI is allocated to an UE having a RRC connection and identifies thb'UB Siidthin iti servkig RNC. 
T0.2.3.4 SRNG identity - . . . 

Identifies the serving RNC for an UE having an RRC connection. " : ^ 7 : •' . .V , 

1 0.2.3.5 Initial UE identity . . ... . ' .'1. . ' - ' ■ ' ' 

TTiisinforniation elenienfr identifies the UE at a request of-iin-RRC.ccainection. . 



Parameters 


REFERENCE 


TYPE 


NOTE 
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IMSl 




O 
O 


International Mobile Subscriber Identity . . . . 
Temporary Mobile Subscriber' Identity arid 
Location Area Identity 


One of these . 
NAS-identities" 
is used 




P-TMSI + RAI 
IMEI 




O 
O 


Packet Temporary Mobile Subscriber Identity and 

Routinq Area Identity 

International Mobile Subscriber Identity 





[Note: The use of these identities is pending confirrnution from WG I that the RACH 
payloadwhenthesetypesoflD are used] ■ ^ 



10.2.3.6 Activation time 



; known frame number) in which the operation/changes 



Activation Time defines the frcune number (or offset to some I 
caused by the related message should be executed. 
Current assumption is that a connection based CFN (Connection Frame Number) that is known by MS and SRNC 
could be used. . . . - ■ 



10.2.3.7 Wait time i'^ ' " ■ ; -" ^ '.■ ; -; ;. ' 

Wait time defines the time peri<xltiieU£.^ . i' ' ' ' 

10.2.3.8 Control-only-state timer 

THis IE indicates for- hdv;^' lOHgitfie'UE shall stay itt tbe.controi-orily-state- EdUors note: the exact usage of this IE 
needs some clarification. 

1 0.2.3.9 ^Paging recprd. .. ^. _ . ^ "' • 



Parameters 

Paging originator 


REFERENCE 


TYPE 

M 


NOTE 

UTRAN/CN . . ' • , 


Paging cause 




C 


For CN originated pages 


CN domain identity 




















IMSI 




o 


International Mobile Subscriber Identity 


One of these 

formats is 
used 


For idle 

mode 

pages 


TMSI 




o 


Temporary Mobile Subscriber Identity 


' P-T^ISi 




D' * 


Packet" Temporary Mobile Subscriber Identity 






S-RNn 




O 


For connected mode pages 


SRNC identity 









RRC PfotocorSpe<ilfidatl(Dn 
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uZVrLZ^^ connection esmblishment request (oraginati.g adl, emergency call, paging response, location 
update request, forward mter-system handover etc). 

10.2.3.1 1 Release cause • v - . ' : - ~ . . 

Cause for release of RRC connection. — - '■/i:!'?': ? ■ 

10.2.3.12 Rejection cause ^ : TV : • "m : nV:" V^:^,:: / — ; 

Cause for rejection of RRC connection estiibUshment request. 

10.2.3.13 Paging cause . .... ^ ....... . 

Cause for a CN originated page. Edi^rsmt^^TUu^ clarificatiorL^ - ^' 

10.2.3.14 InitiahUE capability ™- ^ .r 'l^y ' 1 ' 7 7 

^ ''^^^ ^ capability information given in tfie RRC coiinectidn request b^ssa^e. The exabt type of infbnilation 

10.2.3.15 Power control capability _ 



IS 



Parameters 


REFERENCE 


TYPE 


NOTE vl:.-..,.^:. '±...:\J.: ^ .r.J. 


Transmission power capability - 




M • 





















Note: The WGl and WG4 discussion should be concluded before the contents of this IE can be finalized. 

10.2.3.16 Code resource capability 



Parameters 


REFERENCE 


TYPE 


NOTE 


DL multi-code capability 








UL multi-code capability 








DL Spreading factor capability 








UL Spreading factor capability 









Note: The WGl and WG4 discussion should-b&concluded before the contents of -Uiis IE can be finalized.; 

1 0.2.3. 1 7 UE mode capability 



Parameters 


REFERENCE 


TYPE 


NOTE • : / . i , 


System capability 
(UMTS/GSM/others) 








UMTS capability (TDD/FDD) 








Chip rate capability 








Radio Frequency capability 








Variable duplex distance capability 
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Note: The WGl aiid WG4 discussion should be aincluded before the-COTtents of this. Ip pan be Onalized. . 

10.2.3.18 Transport channel support capability 



Parameters 


REFERENCE . 


TYPE 


NOTE 


Maximum number of DCHs 








Support for Transport CH 

















Note: The WGl and WG4 discussion should be concluded before the contents of this IE .can be finalized; 



10.2.3.19 Ciphering capability 



Parameters ; 


REFERENCE . 


TYPE 


NOTE 


Ciphering Algorithm capability 




M 





















. Note:, The WGl luid WGr4 discussipu. should tje. cqucluded before Ihe contents of this IE can be finaUzed, 



10.2.3.20 Macro diversity capability 



Parameters 


REFERENCE 


TYPE 


NOTE 


Maxirtium numb'dr of-RLs^-: 




M - 





















Note: The WGl iuid WG4 discussion should be concluded before the co IE can be finalized. 

10.2.3,21 Cell update cause 

Indicates the cause for s cell updiite. Examples of aiuses lue cell reselection and periodic cell update. 

1 0.2.3.22. URA.upd . .. ;V - ; • 

Indicates^the cause for s :URA update. Examples of causes)ttfe;change of URA and periodic URA update.,. 



10.2.3.23 Number of Quick ReiDeai:;' . . ' 

Indicates the number of quick repeat for RRC Connection Release Complete'message. 



•RRC Protocol Speafication * 6% TS 25.331 Vl .1 .0 (19^9:66) 

10.2.3.24-lnter^?ystem handover- failure ''"'^.^'■''^■■ }J..:T''._.'.- . .. 

The purpose of this IE is tb provide a reason for- the fiiilure of the Iiuer-systein hjipdover. 

10.2.3.25 Tfansmissidn probability • ' - • . . . 

Indicates the probability for a rnpbiJe, to be aUowed to transmit oin a DCH controlled by DRAG procedure. 

10.2.3.26 Maximum bit rate ■■ ..... 

Indicates die maximum akx bit rate allowed on a DCH controlled by DRAG procedure for the transmission period 
(Transmission time validity). - ' ._- . .„ . . . 




10.2.4 Radio Access Bearer Ififormatiorr elements " - - 

.10.2.4.1 RAB identity ' ' v t, . .. ... 

ka identification number for the RAB affected by a certain message. 

1.0.2.4.2 RLC infp . 
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Parameters 



RLC mode 



REFERENCE 



TYPE 



M 



RLC in-sequence delivery 



RLC FDD size 

RLC transmission window size 



RLC retransmission into 



NOTE 



Indicates if the RLC entity for a certain 
RAB should use Acknowledged, Non 
Acknowledged or Transparent mode 
data transfer. /A/ofe; It is FFS if this. ; 
parameter always is tfie same in both 
UL and PL] 



Uplink RLC 
info 



Indication it RLC should preserve the 
order of higher layer PDUs that were 
transmitted through RLC. [Note: It is 
FFS if this parameter always fs the 
same in both UL and PL] . • - 



C 

o" 



same in u^ut — , 

Size of RLC Protocol Data Units. See 
Note 1 



M 



A flow control parameter used to set 
the maximum number of RLC PIDU?. 
sent without getting them 
acknowledged 




This could be the number of attempts 
to retransmit a RLC PDU before it is 
discarded, or different timer values. 



Notel: RLC PDU size may te derived from transport Mock size and n.t explicitly transfered across tHe radio,, 
interface. 



10.2.4.3 Signalling link type 



Tte purpose of ^ Si8«».U.g Type i.^aU». e,em»t is » indict .he ^ ^ ^ 

signalling link. 

Ea.. possible vM„eofSi.„aingU„U Type i„f»m».o„e,e.e„trefe,s,oap,edefi„edse. Of par^,^^ 
10.2.4.4 RAB multiplexing info 

A multiplexing optiou for each possible transport channel tbis RAB can be multiplexed on. 
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Parameters 

Transport channel identity 



Logical channel identity 



REFERENCE 



MAC logical channel priority 



Transport channel identity 



Logical channel identity 



TYPE 



O 



NOTE 



This'is the ID of-a-transport 
channel that this RAB could be 

mapped onto. 

This parameter. is used to- 
distinguish logical channels 
multiplexed by MAC on a 
transport channel. 



This includes both priority, 
between difiererit users iriihc 
when using a common or 
shared channel, aiid between 
different RABs (or logiciil 
channels) tratBc for a certain 
user. Different priorities tor 
one users' RABs are mapped 
(through the.MAC'S'T mid . 
C/TMUXes)tothe'ITC 
selection algorithm. 

[I^ote:. Usage :and precise, 
meaning of this is FFS.] 



Upiink- 

multi- 

plexing 



For 
each 
multi- 
plexing 
option 



Note: Thenecessity of dividing RAB multiplexing imo in L^iink aid downlink is F^.' 



Downlink 
multi" 
1 plexing 



10.2.5 Transport CH Iniformatidn eiements " 

10.2.5.1 Transport Format Combination Set 

Indicates the allowed ojmbinations of already defined Transport formats. 

10.2.5.2 Transport Format Combination Subset 

indites Which Transport tbnnat combinations in the alr.,dy,defmed Tr^sp^^f^e combpadox, set that are; - 

10.2.5.3 Transport channel identity - - r 

mfb^ation u u»d «,^s^,.>^ '^^spon^m.^O»>>>c«^^, dedla,«l ™sp„n ca».els). 

10.2.5.4 Transport Format Set (TFS) " " ' ' . . ; 1 ; v:: 



Parameters 



Transport block s\ze{s) 



Transport Block Set SizeT s) 
Transmission time interval 



Type of channel coding 



REFERENCE 



TYPE NOTE 



(dynamic)- 



(dynamic) 



(semi-static) 
(semi-static) 



(semiTStatic) 



.?r?PP 
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1 0.2.5.5 Dynamic Qontrpj .. 



Indicates if this transpcirt ciranneris controlled by DRAG procedure or not. 



1 0.2.5.6 transmissiori;tiWe yal^^^^^^^^^ 

Indicates the' duration for whidi pmnissibn is-granted on a DCH controlled by DRAG procedure. 

10.2.5.7 Time duration before retry - 

Indicates the time duration before retrying to get the tritnsmission pennission on a DGH controlled by DRAG 
procedure, iri-Cfise permission- lifis not beeti griiiited. - -- - - . . ~ - . 



10.2.5.8 Silent period duration before release 

Indicates the maximum silent period duration before releasing the resource. This parameter may be merged with the 
Fkp-b parameter defined in die Transmission stop and resumption control* procedure defined in [1]. 



(Note: [1] RANAVGl SI. 14 document) 

1 0.2.6 Physical GH Infornhatioh ele^^^ 
10.2.6.1 Frequency info 



Parameters 


REFERENCE 


TYPE 


NOTE 


Frequency number 




M . , 


Designate thsi centerf requency 
of the uplink carrier 


Duplex distance 




O 




Chip rate . 




O 




Mode ' ^ . " : * * 




o- 


Designate FpP"or. TDD, mode . " 



10.2.6.2 Primary CCPCH info. ■ 
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Parameters - ^ 


REFERENCE 


TYPE 


NOTE 


DL scrambling code - - • 




M 


DL scrambling code used for 
Primary CCPCH 



10.2.6.3 Secondary CCPbfTi/info! 



Parameters 


REFERENCE 


TYPE 


NOTE 


DL scrambling code 






Only heeded if different from DL 
scrambling code of Primary 
CCPCH . -C^ 


Channelization code 




M 





10.2.6.4...PRACH info 



Parameters 


BEFEBENQE . 


TYPE 


NOTE 


Access slot 




M 


For each' allowed access slot for 
the preambles 


Preamble spreading code ' 




M 


For eacb code to use for spreading 
of the preamble. There is also.a. 
one to one mapping from preamble 
code to what scrambling code to 
use for thejpaessage.part. 


Preamble signature 




M 


For each allowed preamble 
signature. 


Spreading factor - ' * ' . 






For -each rate or *SF thatiire . ~-- - 
allowed to use on the data part (P 
branch) in the message part of the ' 
random-access 



10.2.6.5 PRACH power control info 




Parameters 


REFERENCE 


TYPE 


NOTE I- : ir/j 


UL target SIR 




M 


The usage of these parameters 
needs clarification and are also 
dependent on.the WG1 RACH 
discussions. 


Primary CCPCH DL TX power 




M 


UL Interference 




M 


Constant value 




M 



10.2.6.6 Uplink DPCH info 



Parameters 


REFERENCE ' 


TYPE ' 


NOTE 


UL scrambling code 




M 


What short or long uplink 








scrambling code a certain UE 








should use 
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DPCCH channelization code" ' : - 


- 


M 


SF of the chaniK 
for control pjirt. 

of this paramete 


slization code; I 
fthe necessity 
rLsFFS.I . ' 


DPDCH channelization code 




M 


SF of the 
channelization 
code f or dkta ' 
part 


For each 
DPDCH 



1 0.2.6.7 Dptihk .D=PCB pLQwer control ihf 

Interference level measiMidV.aW«^ at theUtRAN.axesspbm^ used by UE to set DPCH taitial. qutput power. 



1 0.2.6.8 Downfink DPGH info - ■ 



Parameters 


REFERENCE 


TYPE 


NOTE 


DL scrambling code 




O 


Only needed If diffe 
scrannbling code of 
CCPCH 


rent tronn UL 
Prin^iary 


DL chaiinelization. code - ; : ~ 


V; 


W " 


Channelization 
codes to be used 
in the downlink for 
DPCH 


For each 
DPCH 



1 0.2.6.9.Uplink ti?in6sl6t 'info 



Parameters " . . ' 


REFERENCE- 


TYPE 


NOTE 




SlQtnupiber ; - • 

.v-r/;i • ^ i.. ' > 


i 


M- 


Timeslot to be 
used in uplink 
(TDD only) 


For each slot 



10.2.6.10 Downlink timeslot info 



Parameters 


REFERENCE 


TYPE 


NOTE 




Slot number _ 






M ■ 


Timesjpt to be 
used in 

downlink (TDD 
only) 


For each, slot' 



10.2.6.11 SSDT indicator ...... ^ 

This information element indicates the status (e.g. initiated/terminated) of the Site Selection 

Diversity Transmit power control (SSDT). In the direction UTRAN to UE it is used to ch^ge the SSDT status. In the 
direction UE to UTRAN it is used fo confirm the SSDT status-by.,the UE. " 



10.2.6.12 Gated Transmission Control info (FFS) 
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Parameters 


REFERENCE 


TYPE 


NOTE 


Gating pattern 




M 


ndicatss Derioriir??! nr ranrlnm 

(FFS) 


Gating rate 




M 

.j 


Indicates no gating, 1/2 gating, 
1/4 gating or 1/8 gating 
(FFS) 


Gating activation time 




M 


FFS 



10.2.7 Measurement Information element^ ^ ■ ' 
10.2.7.1 Measurement Identity Number 

A reference number that is used by the UTRAN at modification and release of die measurement, md by the UE in the 
measurement report. ' = • v= ■ ' - i. , v 



10.2.7.2 Measurement Command ; - : r:^; : 

One out of three different measurement commands 

• Setup: Setup anew mejisurenienti - ' a . ^ i . : .. : -^t ^ - • 

• Modify: Modify a previously specified measurement, e.g. chiuige the reporting criteria. 

• Release: Stop a measuranent and clear iiil informiatiori iri die^^ diat ^ire rekited ta^hut measnr^feA 

10.2.7.3 Measurement Type r -J] " f ' liJH- r ?;^''T 7r y"*'".::? ™:r.~::,.;^i 

One of die types from a predefined list where ejicb type describes what the UE shall measure. Tlie types are: 

• Intra-frequency measurements 

• Inter-frequency measuremen ts 

• Inter-system measurements 

• Traffic volume measurements 

• Quality measurements 

1 0.2.7.4 Reference time difference to cell 



The reference time difference to cell indicates die time difference between die prim^u-y CCPCH of the current cell and 
die primary CCPCH of a neighbouring cell. It is notified to UE by System Infonnation or Measurement Control 
message. 



BR.CPfotocol Specification 

In case of macro-diversity the reference is the primary CCPCH of one the cells used in the active set. 
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Editors note: Exactly fiow the:r£fkrence c?ll is pointed out in this case in the messages is fFSr 

10.2.7.5 Measured time difference to cell 

The measured time difference to cell indicates the time difference which i.s measured by tetween the primary 
rcP^roCerrrent cell ±e primary CCPCH of a neighl^uring cell. It is notified to SRNC by Measurement 
Report message or Measuremeiulufonnation Element u),odier,ERCmess£ig^^^^ •, Y ■ • • ; , 

m case of macro-diversity the reference is the primary CCPCH of one the cells used in the active set 
Editors note: Exactly how the reference ceil is 'p6inted out in 'tfUs case in the messages is FFS. 



10.2.7.6 Measurement reporting mode ; •., • . 

Contains the type of Measurement Report transfer mode and the indiaition of periodiaa/eyent trigger. 



Parameters 

Measurement Report Transfer Mode 


REFERENCE. 


TYPE 


NOTE 

Acknowledged/ 
Unacknowledged 


Periodical Reporting / Event Trigger 
Reporting Mode 




M 


Periodical reporting / Event? 
triqqer 



10.2.7.7 intra-frequency cell info 

Contains the meiisurement object information for mintra-frequaicy measurement 
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Parameters 



Primary CCPCHHnfo 
Primary CCPCH PL TX power 
UL Ioad •: 



Referende-time difference to cell 



REFERENCE 



TYPE 



M 



O 



NOTE 



FFS 



10.2.7,8 lnter-frequepcycell"iof0. - - V .l' V '* ... 

Contains the measurement object information for £m inter-frequency measWemeiu. 



Parameters 

Frequency info 


REFERENCE 


TYPE 


NOTE 


Primary CCPCH info 




M 

M • 




Primary CCPCH DL TX power 




0 


FFS 


ULIoad , . 
Reference time difference to cell 




o. 

0 


FFS - . • ■ - . - 

FFS . .. 



10.2.7.9 Inter-system cell info 



Coritiiiris the measurement object information for-^m inter-system 



measuremenL 



Parameters . i 

System type 


REFERENCE 


TYPE 


[note...-; --^. 'c . 






M 


E.g. GSM 


System specific measurement info 






E.g frequeacy, tirneslot, colour . 
code, output power. 



10.2.7.10 Traffic volume measurement object 



. - i: ^ iLc :'}□..: ilS?^ -I£ i 

Contains the me^ufeDaeiit Dbject,infQOTa^ 



Parameters 


REFERENCE 


TYPE 


NOTE 


Target Transport CH ID 




M 





10.2.7.1 1 Quality measurement object (FFS) 

(Note: Only the section is made,) 



10.2.7.12 Intra-frequency measurement quantity • • ■ • 

The quantity the UE shall measure in aise of intra-frequency measurement. It iilso includes the tilterine of the 
measurement!?- "ittixug ui uic 
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Parameters 


REFERENCE 


TYPE 


NOTE : "^"^ i 


Primary CCPCH RX Ec/io 




0 




One of these is 
maridatpfy. 


Primary CCPCH RXSIR 

(RSCP/ISCP) ■ 




0 


FFS. . . 


Primary CCPCH RX power (RSCP) 




0 


FFS 




Path loss 




0 


FFS. . 




Path loss plus UL load 




0 


FFS 





(Note: Above measuremeats except for Ec/io ijre act concluded in WQi) ^ 



1 0.2.7. 1 3 inter-f requenc^ me.asu remg^ (FfS) - , ..: 

The quantity the UE shJ^^ cas^ of intCT-frequ^^ It also includes thefiltering of the 
measurements. ■ " : . M 



Parameters 


REFERENCE 


TYPE 


NOTE 




Ec/io 




O 


FFS 


One of these is 


DL Path loss 




O 


FFS ■ ' 


hnandatory'' 


SIR 




o 


FFS 




DL path loss plus UL Interference 




0 


FFS 




Recelved'siqnaVcVde power (RSCP) 




"0 


FFS 





10.2.7.14 Inter-system measur^^ 

The quantity the UE shcoll meiusure in case of inter-system measurement. It also includes the filtering of the 
measurements. 



Parameters 


REFERENCE 


TYPE 


NOTE 


Ec/io wr-. 




Q V ^ 


FFS;.. r..:. 


Pn^,;Of. these is 
mandatory 


Signal strength 




0 ' 




Path loss 




O 


FFS 


Colour code - ■ - 




M. 


GSM only. . - - . 



10.2.7.15 Traffic volume measurement quantity 

Contains the measurement quaiuity information for a traffic volume measurement. 



Parameters 


REFERENCE 


TYPE 


NOTE 


RLC buffer payioad 




U 





(Note: If there is no other measurement qumitity, this paraineter ciui be removed since it be implicitly known by 
UE.) 
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10.2.7.16 Quality measurement quantity (FFS) 

(Note: Only Jhe section is made.) ■': ' . ' ' • . 




10.2.7.1-7 Intra-fr-equeney -reporting quantity-. - - 

Contains the reporting quantity information for an intra-frequency measurement. 



Parameters 


REFERENCE 


TYPE 


NOTE 


Primary CCPCH RX Ec/lo 




O 




Primary CCPCH RX SIR 
(RSCP/ISCP) 




O 


FFS 


Primary CCPCH RX Dower f RSCP^ 




o 


FFS 


Path loss 




o 


FFS 


Path loss plus UL load 




o. 


FFS. - ... 


Measured time difference to cell 




o 












DL Transport CH BLER 




o 




DL Transport CH BER 




o 




UE Transmission Power 




o 




UE Position 




o 




Cell ID 




o 


FFS 



(Note: It is FFS whether the reporting quantity parameters .used in.different. measurement types can be used commonly 
for all types of reporting quantity. If they can/only "Reporting Quantity" i^ "enough instead of specifyirtd S types of - 
reporting quantity.) 



10.2.7.18 Inter-frequency reporting quantity (FFS) , 



(Note: Only the section is made.) 



1 0.2.7. 1 9 Inter-system reporting-quantity (FFS) 



(Note: Only the section is made.) 
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Contains the reporting quantity infonnation for a trjiffic volume measurement. 
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Parameters 


REFERENCE 


TYPE 


NOTE 


RLC buffer payload for each RAB 




O 












DL TransDort CH BLER 




O 




DL Transport CH BER 




0 . 


FFS. ... - 


UE Transmission Power 




0 




UE Position 




0 




Cell ID 




0 


FFS 



(Note: It is FFS whether the reporting quantity parameters used in different measurement types can be used commonly 
for all types of reporting quantity. If Jhey can, onlyJ'Repprting.Quantity" is enough instead of specifying 5 types of 



I types of reporting 
reporting quantity. 



10.2.7.2'1 •Quality-reporting. quantity- (FES) 

(Note: Onlyjhe section. mcAde- 



10*2,7^22 intra-frequeripy^iTiea^^ criteria V.":. '. . , ..o " ; -7.:' 

The triggering of the event-triggered reporting for mi intra-frequency measurement. All events concerningMntra- 
frequency measurements are labeled 1x where x is a, b, c... 

Event la: A Primary CCPCH enters the Reporting Range [Note1] , . _ ^ - . 

Event lb: A Primary CCPCH leaves the Reporting Range [Note2] 

Event 1c: A Non-active Primary CCPCH becomes better than an active Primary CCPCH [Note3] 

Event 1d: Change of best cell [Note4, 5] 

Event 1e: Other types of ranking of Primary CCPCHs (FFS) 



Parameters 


REFERENCE 


TYPE 


NOTE 










Common 
parameter for all 

events 


Max number of 
reporting cells 




M 














For each event 


Event H) 




M 


la, lb, Ic, Id or le 
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c 


Reporting Range 


-J 




In'event"la,'Jb " 


Hysteresis 




c 


Id event Ic.ld 


Time to trigger . 


' : t ' ' . 


M 


Indicates the period of time 
between the timing of event 
detection and the timing of 
sending Measurement Report. 


Aifibunt of reporting 


■ - 


M * 


Measurement for tfie 'Indicated 
Transport CH jp1s "released" 
after the indicated annount of 
repdrtmg'from the UE itself; ' 

FFS-; -- ; ^; '^r'- 


iippul inly interval 






Indicates theinterval of periociical ■ 
report during the event is in the 

FFS ... . 


atkar DOr^OOLJ ^ 1 a: ■ *-t 









[Note2: whether or not PCCPCH can be noh-actiyejs FFS] , ; 

[NoteS: Details are FFS: it. has been suggested to divide this event irito Xsno cases; I) a non-active PCCPCH exceeds 
the weakest active PCCPCH, II) ,a nop-active PCCPCH exceeds the jstrongest active PCCPCH] ' 

[Note4: When best PCCPCH in active set changes, ail active cells ai^e reported.] ' 

[NoteS: Whether this- event can resttlt in the reporting of non-actrve-cells in additiiorr to actlve cells-rs FFS.] - 



10.2.7.23 Inter-frequency measurement reporting criteria (FFS) 

The triggering of the measuremeiu report, e.g. periodiaxl, event-triggered or iininediate reporting for an inter- 
frequency measurement. Here is idso specified if the measurement report should be transmitted using either 
acknowledged or unacknowledged data transfer on tiae DCCH. 



Parameters 


REFERENCE 


TYPE 


NOTE 


. 'i'.' • ■ • • ( • • , 




■ . "i 





1 0.2.7.24 Inter-system measurement reporting Grkeria (FFS) . 

The triggering of th'e measurement report, e.g. periodical, event-triggered or immediate reporting for 
an in ter-system measurement. Here is also specified if the measurement report should be transmitted 
using either acknowledged or unacknowledged data transfer on the DCCH. 



.?r?PP 
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10.2.7.25Traffic volume "measuremGntre^^ . ' 

Contains tJae measurement reporting criteria information for a triiffic volume meaSureiiient. 



Parameters _ 


REFERENCE.. 


TYRE 


NOTE 


Common parameter 
for ail ^transport CH 


















iFor each 

transport-GH 


Transport CH ID 




M 




Threshold " ' " 





M- - 






Time to'trigger 




M. • 


IndFcates the period of time 
between the timing of event 
detection and the timing of 
sending Measurement Report. 


Amoimt of reporting 




M 


Measurement for the indicated 
Transport CH E) is "released" 
after tlae indicated amount of 
reporting. froni. the UE itself. 

FFS- - ■ - . 


Reporting interval 


=v r.i! ' • "v : 


M 


Indicates the interval of periodical 
report during the event is in the 
detected statd" " - ■ ■ ' 

FFS ■ - " ■ ^ 


- • . < • — r ^ 









10.2.7-26 Quality measurement reporting criteria (FFS) 



(Note: Only the section is made,) 



10.2.7.27 Periodical reporting criteria 



Contains the,p^ipdicai"repprting criteria infQnnntion..It isjieceswy pnly in. tfce. periodical reporting mode. 



Parameters 


REFERENCE 


TYPE 


NOTE ■ 




Max number of 
reporting cells' 




C) 


Indicates the ma?dmum number of 
cells to report. " ' ' 
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Amount of-reponiug 




0 


Measurement is "released" after 
the indicated amount of reporting 
from the UE itself 


RepOTtiug interval 




0 


Indicates the interval -of 
periodical report. 











10.2.7.28 Intra-frequency measurement event results 

This m contains the measurement event results that are reported to UTRAN for intra-frequency measurements. 



Parameters 


REFERENCE 


TYPE 


NOTE 


Event ID 




M 




Primary CCPCH Info „ . 




M 





















10.2.7.29 Inter-frequency measurement event res ' " * ■ " . 



This m contains the measurement event results that are reported to UTRAN tor intetrfrequency m^urem^nts. 
The further division of this IE into pariuneters is FFS. ' . - 



10.2.7.30- Inter-system measurement- event results (FFS) 



This E contains th^emeasurement eve^^ 

The further jiiyision of thO ' " ~ " * ^ ' --^ iTS 



10.2.7.31 Traffic volume measurement event results ... 
Contains the event result for a traffic volume measurement. 



Parameters 


REFERENCE 


TYPE 


NOTE 


Transport OH ID - ■ . 




M • 
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1 0.2.7.32 ..Quality.m'easjjre.meiit event, results. (FFS) 

(Note: Only the section is made,) 



10.2.7.33 Measured results 



Contains the measured results of the quantity indicated optionidly by Reporting Quantity in Measurement < 
"Measured results" can be used for bodi event trigger mode and periodical reporting mode. 



Parameters 


REFERENCE 


TYPE 


NOTE ' : 


RAB ID 

+ 'RLC"buffers payload 




O 












PCCPCH Info 

+ Primary CCPCH RX Eo/lo 




o 




PCCPCH Info 

+ Primary CCPCH RX SIR 

(RSCP/ISCP) 






FFS 'i.. -'^ ^ . .. - ■ 


PCCPCH Info 

+ Primar\^ CCPCH RX^ib'o^er (RSCPy 




o 


FFS 


PCCPCH Info 
+ Path loss 




p 


FFS 


PCCPCH Info 

+ Path loss plus UL load 




o 


FFS 


PCCPCH Info 

+ Measured time difference to cell :~ 




o 












DL Transport CH BLER 




o 




DL Transport CH BER 




o 


FFS 


UE Transmission Power : i-i • ' ^'J 






:rr:.:/:: -}\( ' -r- ■' ' ■ ■ * 


UE Position 




o 




Cell ID 






FftS y- '--J - t-.-i- 











10-2.8 Other Information elennents ' ' 
10.2.8,1 BCCH modification info 

Indicates modification of tlie System Information on BCCH. 



Parameters 


REFERENCE 


TYPE 


NOTE - ' 


BCCH modification type 




M 


FFS 


Modification time 




O 


FFS 
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10.2.8.2 Inter-system message 



This Information Element conttiins one or sevend messages tbat are structured'aiKl coded- according to the 
specification used for the system type indicated by the first parmneter. 



Parameters 


REFERENCE 


TYPE 


NOTE 


System tvpe 




M 


E.g. GSM 


Message(s) 




M 


Formatted and coded 
according to specification for 
the Indicat.ed'system type.; " / ' 



1 1 Message and Information element abstract syntax (with 
• ASN.1) 

This chapter contains definitions for RRC PDUs and ffis using a subset of ASN.l as specified in IZOl. 
> PDUaiid.m definitions iire grouped; into. sep^u^ate.ASR^ ,., , 

Note that the proposal is to keep both chapter Wand J I (at least until all messages and information 
elements are fully discussed and agreed by 3GPP RAN WG2), Chapter 10 is intended Jo give an 
abstract description (in English) of the messages and information elements whereas chapter 1 J should 
contain the exact normative definitions with all necessary details. 
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1 2 Message transfer syntax 



Tnmsfer synuix for RRC PDUs is derived from their abstract syiitiix definitions by use of encodinjg 
rules. 



13 ProtCK^ol states -iij-^ . .. - 

Service state diagram(s) of tbe RRC sublayer. (E.g. like in GSM0407.) 



14 Protocol timers, counters and other parameters 

Description of timers jiiid counters and possible othei ptu-ameters related to RRG procedures.. 



15 Specific functions (if applicable) 

< description of chapter scope and contents > 



16 Handling of unknown, unforeseen and erroneous 
protocol data 

This section specifies procedures for the handling of unknown, unforeseen, and erroneous protocol 
data by the receiving entity. Tliese procedures are called "error hjmdling procedures". 



17 SDL 

' This section describes th& functionality of the protocol in descriptive SDL. 



18 Appendices: Examples of operation 



19 History 
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